Brevet FR2984647A1 — publié le 20130621

Accréditations Anonymes L'invention concerne le domaine des systèmes d'accréditation anonyme pour l'accès à des services. Dans un système d'accréditation habituel, une organisation de confiance émet, pour certains utilisateurs, des accréditations certifiées portant sur un ou plusieurs attributs de cet utilisateur. Une telle organisation peut être, par exemple, une mairie émettant des accréditations certifiées consistant en des cartes d'identité, lesquelles présentent un certain nombre d'attributs associés à l'utilisateur du type nom, prénom, date de naissance, adresse, etc. Cette organisation peut également être une université émettant des accréditations certifiées consistant en des cartes d'étudiant, lesquelles présentent certains attributs associés à un étudiant du type nom, prénom, numéro d'étudiant, études suivies, etc. Lorsqu'il souhaite accéder à un service offert par un organisme tiers agissant en tant que fournisseur de services, l'utilisateur peut alors vouloir utiliser de telles accréditations certifiées de façon anonyme, c'est-à-dire en minimisant l'information qu'il fournit à ce fournisseur de service afin d'en obtenir le service désiré. Par exemple, l'accès à certains services spécifiques peut être restreint aux habitants d'une ville. Dans un tel cas, l'utilisateur doit alors prouver qu'il habite bien la bonne ville, de façon certifiée par la mairie, mais il peut ne pas vouloir révéler les autres attributs le concernant sur sa carte d'identité, tels que son nom ou son adresse exacte. De façon similaire, un étudiant peut vouloir bénéficier d'une réduction sur un service offert par un organisme tiers. L'étudiant doit alors prouver qu'il possède une accréditation provenant (par exemple) d'une université, mais peut ne pas vouloir révéler les autres attributs le concernant sur sa carte d'étudiant, tels que son nom ou les études qu'il suit. Pour répondre à ce besoin d'anonymat, il est possible d'envisager des systèmes d'accréditation utilisant des techniques cryptographiques proches des signatures de groupe ou des signatures aveugles. Dans le cas des signatures de groupe, l'organisation certificatrice signe, lors de la phase de création de l'accréditation, l'ensemble des attributs associés à l'utilisateur en ne produisant qu'une seule signature. Cette signature doit être telle que l'organisation certificatrice elle-même ne doit pas être capable d'utiliser cette accréditation afin de se faire passer pour l'utilisateur, ce qui est par exemple possible en utilisant des techniques liées aux schémas de signature de groupe. L'entité de confiance est l'organisation qui délivre des accréditations. L'entité de confiance peut être notamment une mairie, ou encore une université. Une fois l'utilisateur en possession d'une telle accréditation, il peut révéler un ou plusieurs attributs qui lui sont associés, en fonction de la demande de l'organisme tiers agissant en tant que fournisseur de services auprès duquel il requiert un service, en générant, à l'instar des techniques de signature de groupe, une preuve de connaissance des attributs non révélés et une signature sur l'ensemble des attributs, révélés ou non, sans divulguer ni les attributs non révélés ni la signature de l'organisation certificatrice. L'utilisateur préserve de ce fait son anonymat vis-à-vis du monde extérieur. Dans ce cas de figure, il est connu d'utiliser un schéma de signature permettant de signer plusieurs messages/attributs en une seule signature et où le possesseur de la signature est capable de faire une preuve de connaissance de la signature et des messages signés, sans révéler ni la signature, ni l'ensemble de ces messages/attributs qu'il souhaite cacher, tout en gardant la possibilité de donner en clair le ou les attributs qui lui sont demandés par l'organisme tiers. Un tel schéma de signature est consommateur en temps de calcul puisqu'il nécessite de cacher explicitement les attributs non révélés. La taille de la preuve dépend donc du nombre d'attributs initialement certifiés par l'entité émettrice. Par ailleurs, sa mise en oeuvre pratique nécessite l'utilisation de données cryptographiques de taille importante, comme cela est le cas dans la technologie Idemix proposée par IBM. Dans le cas des signatures aveugles, l'idée consiste à faire signer de façon aveugle les attributs par l'organisation certificatrice. L'utilisation d'une telle signature aveugle rend le système d'accréditation plus efficace, au détriment cependant d'une traçabilité accrue de l'utilisateur, puisque l'organisation certificatrice est impliquée lors de chaque demande d' accès. Un exemple de ce type de technique est repris dans la technologie UProve proposée par Microsoft. L'invention vise à améliorer la situation. L'invention se rapporte notamment à un procédé de contrôle d'accès anonyme à un service, dans lequel, un dispositif électronique utilisateur stockant un ensemble certifié d'attributs et une clé de modification, ledit ensemble ayant été certifié par un dispositif électronique certificateur à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification, le procédé comprend: /al/ la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs requis pour l'accès anonyme audit service, 1a2/ la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Ce procédé est avantageux notamment en ce qu'il permet au dispositif électronique utilisateur de prouver au dispositif électronique vérifieur qu'il détient des attributs donnant accès à un service donné, sans pour autant avoir besoin de divulguer au dispositif électronique vérifieur des attributs autres (susceptibles de porter atteinte à la vie privée). L'invention se rapporte également, notamment, à un dispositif électronique utilisateur agencé pour stocker une clé de modification ainsi qu'un ensemble certifié d'attributs, l'ensemble d'attributs stocké étant certifié par un dispositif électronique certificateur à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans ledit dispositif électronique certificateur ainsi qu'à ladite clé de modification, le dispositif électronique utilisateur étant agencé pour modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs requis pour l'accès anonyme audit service, et pour déterminer, à l'aide de la clé de modification, la signature de l'ensemble d'attributs modifié, afin de permettre le contrôle ultérieur, par un dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Ce dispositif est avantageux notamment en ce qu'il est agencé pour prouver au dispositif électronique vérifieur qu'il détient des attributs donnant accès à un service donné, sans pour autant avoir besoin de divulguer au dispositif électronique vérifieur des attributs autres (susceptibles de porter atteinte à la vie privée). L'invention se rapporte également, notamment, à un système de contrôle d'accès anonyme à un service, comprenant un dispositif électronique utilisateur selon un mode de réalisation de l'invention, et au moins l'un des deux dispositifs suivants: - un dispositif électronique certificateur agencé pour certifier un ensemble d'attributs à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans le dispositif électronique certificateur ainsi qu' à une clé de modification, de manière à permettre au dispositif électronique utilisateur, lorsqu'il a préalablement stocké l'ensemble d'attributs certifié ainsi que la clé de modification, de modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs requis pour l'accès anonyme audit service, et de déterminer, à l'aide de la clé de modification, la signature de l'ensemble modifié, - un dispositif électronique vérifieur agencé pour recevoir du dispositif électronique utilisateur un ensemble certifié d'attributs, et pour contrôler que la signature électronique de l'ensemble reçu correspond à une signature valide d'un dispositif électronique certificateur. L'invention se rapporte également, notamment, à un programme d'ordinateur agencé pour mettre en oeuvre un procédé selon un mode de réalisation de l'invention lorsqu'il est exécuté par un processeur. L'invention se rapporte également, notamment, à un support de stockage non transitoire lisible par ordinateur, stockant un programme d'ordinateur selon un mode de réalisation de l'invention. D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels: - la figure 1 illustre un procédé selon un mode de réalisation ; - la figure 2 illustre l'architecture d'un dispositif électronique utilisateur selon un mode de réalisation ; - la figure 3 illustre un système selon un mode de réalisation ; La figure 1 illustre un procédé selon lequel, l'axe du temps t étant orienté du haut vers le bas, après une première étape d'initialisation INIT (indiquée en pointillés car elle ne fait en l'occurrence pas partie du procédé), le procédé modifie (lors d'une étape MODIF) un ensemble d' attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP en effaçant les attributs FIRST_N, LAST_N, BIRTH_P, ADDR, STATE, CSHIP et en ne conservant que les attributs BIRTH_D, CITY. Le procédé détermine alors (durant une étape DETERM) une nouvelle signature de l'ensemble d'attributs dont on a effacé les attributs précités. Une première signature avait été préalablement calculée durant l'étape INIT, pendant laquelle un dispositif électronique certificateur CERT_SRV avait certifié les attributs pour le compte du dispositif électronique utilisateur ID_CARD. Le procédé peut être suivi d'une étape (indiquée en pointillés car elle ne fait en l'occurrence pas partie du procédé) de contrôle CTRL de la validité de la signature des attributs modifiés par un dispositif électronique vérifieur VERIF_PC. La figure 2 illustre de façon symbolique l'architecture d'un dispositif électronique utilisateur selon un mode de réalisation de l'invention (en l'occurrence une carte à puce ID_CARD). Cette carte comporte un microcontrôleur, sous forme d'un seul composant (bien que les différents éléments soient représentés schématiquement comme s'ils étaient discrets). Le microcontrôleur intègre un processeur PROC, une mémoire vive RAM, et une mémoire morte ROM (pouvant mémoriser un système d'exploitation ainsi qu'un programme d'ordinateur adapté pour mettre en oeuvre un procédé selon un mode de réalisation de l'invention lorsqu'il est exécuté par le processeur PROC). Le microcontrôleur intègre également une mémoire programmable EEPROM (il pourrait évidemment s'agir d'une autre technologie, telle que la mémoire Flash), mémorisant différentes informations, dont une clé de modification MOD_K et huit attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP. La figure 3 illustre un système selon un mode de réalisation possible de l'invention, comprenant un dispositif électronique de certification (en l'occurrence un serveur CERT_SRV), un dispositif électronique utilisateur (en l'occurrence une carte à puce ID_CARD), et un dispositif électronique vérifieur (en l'occurrence un ordinateur personnel VERIF_PC). Le serveur comprend un TPM (Trusted Platform Module), qui est un composant sécurisé, stockant une clé privée de signature SIG_K. L'ordinateur VERIF_PC est connecté à un lecteur NFC lui permettant de communiquer avec la carte ID_CARD. L'ordinateur est également connecté à une porte dont il est en mesure de commander l'ouverture en fonction de ses communications avec la carte ID_CARD. Un mode de réalisation de l'invention se rapporte à un procédé de contrôle d'accès anonyme à un service. Le service peut être un service de toute nature. Il peut s'agir par exemple d'un service consistant à commander l'ouverture d'un tourniquet, d'un sas, ou encore d'une porte, en commandant l'arrêt de l'alimentation électrique d'un électro-aimant retenant une porte en position fermée (ou encore commandant la rotation d'un moteur électrique contrôlant le désengagement d'un pêne de la gâche d'une serrure), donnant ainsi accès à un espace particulier dont l'accès est restreint. Le service peut plus simplement consister à commander l'allumage d'un indicateur particulier (par exemple une ampoule verte ou une ampoule rouge selon que l'accès est ou non autorisé, ou même l'affichage d'un message explicite sous forme de texte sur un écran d'ordinateur), permettant à un contrôleur humain de décider de laisser ou de ne pas laisser passer un autre humain, détenteur d'un dispositif électronique utilisateur. Un dispositif électronique utilisateur ID_CARD (tel qu'une carte d'identité électronique, une carte d'étudiant électronique, ou encore un téléphone portable NFC) stocke (par exemple lors d'une étape d' initialisation préalable audit procédé, ou encore durant ledit procédé) un ensemble certifié d'attributs. Le fait que les attributs sont certifiés signifie qu'ils sont associés à une (ou plusieurs) signature(s) d'une (ou plusieurs) autorité(s). Cette (ou ces) signature est stockée avec les attributs, afin de pouvoir vérifier que ces attributs sont effectivement correctement certifiés. L'autorité peut être par exemple une mairie, habilitée à certifier lesdits attributs. Les attributs peuvent comprendre, à titre d'exemple non limitatif, un prénom FIRST_N, un nom de famille LAST_N, une date de naissance BIRTH_D, un lieu de naissance BIRTH_P, une adresse postale ADDR, une ville de résidence CITY, un Etat de résidence STATE, et/ou encore une nationalité/citoyenneté CSHIP. Ledit ensemble est certifié (par exemple lors d'une étape d'initialisation préalable au procédé, ou encore pendant ledit procédé) par un dispositif électronique certificateur CERT_SRV. Ce dispositif électronique certificateur est typiquement un serveur (mais peut également être tout type d'ordinateur ou de matériel électronique dédié approprié). Il peut comprendre des éléments de sécurité (tels qu'un HSM hardware security module - pour la gestion de clés). Le dispositif électronique certificateur peut être opéré par exemple par la dite autorité ou encore sous son contrôle (il est possible que le dispositif électronique certificateur soit par exemple opéré par un prestataire de service spécialisé pour le compte d'une mairie). L'ensemble est certifié à l'aide d'une fonction de signature électronique sanitisable. Une fonction de signature électronique est une fonction mise en oeuvre par un dispositif électronique, prenant en entrée un message (pouvant être représenté par une suite de bits) et produisant, à l'aide du message et d'une clé privée de signature, une signature de ce message (signature pouvant elle-même être représentée par une suite de bit). La signature est liée au message et au détenteur de la clé privée de signature (changer le message change la signature, et une clé de signature différente produit une signature différente). La signature peut également faire intervenir des paramètres additionnels (tels qu'un aléa pouvant être concaténé au message, permettant ainsi de produire deux signatures différentes lors de deux signatures d'un même message avec la même clé privée de signature). Il est mathématiquement très difficile (en pratique impossible) de déterminer la signature sans la clé privée de signature. Une fonction de signature électronique sanitisable est une variante d'une fonction de signature électronique conventionnelle, selon laquelle on peut modifier a posteriori un couple message/signature de manière prédéfinie et contrôlée par l'entité détentrice de la clé privée de signature (c'est-à-dire l'entité habilitée à signer, à savoir dans le cas général l'autorité précitée ou son prestataire), mais sans interaction avec cette entité. Cette possibilité de modification constitue la seule exception au principe selon lequel il est mathématiquement très difficile (en pratique impossible) de déterminer la signature d'un message sans connaître la clé privée de signature. Plus précisément, le message est modifié, et la signature du message modifié est recalculée en fonction notamment de la modification apportée au message et de la précédente signature. La signature est modifiée (c'est-à-dire recalculée) de sorte à ce qu'une fois modifiée, elle constitue une signature valide du nouveau message (le message modifié). La « sanitisation » peut être publique (tout le monde pouvant alors modifier le couple message/signature a posteriori, dans la limite des modifications autorisées) ou ne se faire que par un (ou un groupe de) « sanitiseur(s) » désigné. Dans le contexte de ce mode de réalisation, le message n'est modifiable que dans les limites définies comme étant admissibles par l'entité détentrice de la clé de signature. Ces limites peuvent comprendre non seulement les modifications possibles (typiquement l'autorisation d'effacer un attribut mais pas celle de le remplacer par un attribut valide différent), mais également les entités habilitées à apporter ces modifications. Le contrôle de l'admissibilité d'une modification de message est opéré à l'aide d'une clé de modification générée par exemple sous le contrôle de l'autorité (mais pas nécessairement détenue par elle). Autrement dit, seul un détenteur de la clé de modification peut apporter des modifications et recalculer une signature légitime. Les signatures sanitisables donnent ainsi les moyens à un signataire de déléguer à une autre entité le pouvoir de modifier un message signé, de telle sorte que le message modifié est toujours considéré comme ayant été signé par le signataire initial (puisqu'il est associé à une signature valide recalculée). Des constructions possibles de fonctions de signature sanitisable peuvent utiliser un schéma de signature standard avec utilisation d'une fonction de hachage. Pour obtenir la propriété de sanitisation, une étape préliminaire à l'utilisation de la fonction de hachage peut consister à diviser le message à signer en plusieurs parties (pouvant chacune correspondre à un attribut), selon ce qui est modifiable ou non par le dispositif électronique utilisateur, puis à utiliser une fonction de hachage caméléon sur les parties modifiables. Une fonction de hachage cryptographique standard peut ensuite être appliquée au résultat ainsi obtenu, puis une fonction de signature électronique conventionnelle peut être utilisée. La clé de modification (ou « trappe de sanitisation ») utilisée par le dispositif électronique utilisateur peut alors correspondre à la trappe de la fonction de hachage caméléon. De telles fonctions de hachage sont décrites notamment dans l'article « Chameleon Hashing and Signatures » de Hugo Krawczyk et Tal Rabin (octobre 1997), dont le contenu est incorporé par référence. Une fonction de hachage est habituellement dénuée de collisions prévisibles, c'est-à-dire qu'il n'est pas possible en pratique de trouver deux messages différents sur lesquels l'application d'une fonction de hachage donne le même résultat. Une fonction de hachage caméléon permet, à l'aide d'une trappe (une clé secrète appropriée) de construire de telles collisions. Pour cela, la sortie de la fonction de hachage est associée à une valeur dite 'aléatoire' qui va varier en fonction du message haché (et pour une collision donnée). Le dispositif électronique utilisateur stocke également une clé de modification afin de pouvoir recalculer la signature du message une fois le message modifié. Le dispositif électronique utilisateur peut être la seule entité détentrice de cette clé de modification. Ladite fonction de signature électronique sanitisable est associée à une clé de signature stockée dans ledit dispositif électronique certificateur (si elle n'est stockée nulle part ailleurs, la non-répudiation de la signature peut s'en trouver améliorée). Ladite fonction est également associée à ladite clé de modification (précitée). Cette clé peut n'être stockée que dans le dispositif électronique utilisateur. Le procédé comprend: /al/ la modification, par le dispositif électronique utilisateur, de l'ensemble d'attributs, ladite modification comprenant l'effacement d'attributs autres que les attributs (par exemple des attributs de date de naissance BIRTH_D et de ville de résidence CITY) requis pour l'accès anonyme audit service, 1a2/ la détermination, par le dispositif électronique utilisateur, à l'aide de la clé de modification, de la signature de l'ensemble modifié, afin de permettre le contrôle ultérieur (soit dans le cadre du procédé selon le présent mode de réalisation, soit dans le cadre d'un autre procédé), par un dispositif électronique vérifieur VERIF_PC, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Un étudiant peut ainsi prouver, en entrant dans un cinéma, qu'il a plus de seize ans (le film qu'il souhaite voir étant interdit aux moins de seize ans) à l'aide d'un dispositif électronique utilisateur tel que sa carte (à puce) d'étudiant, et qu'il habite la ville du cinéma considéré (ce qui le cas échéant lui donne droit à une réduction) sans pour autant divulguer son adresse précise, ses noms et prénoms, ni aucune autre information personnelle non requise pour voir le film et bénéficier d'un tarif préférentiel. Selon un mode de réalisation possible, la détermination de la signature de l'ensemble modifié par le dispositif électronique utilisateur, à l' aide de la clé de modification, est effectuée sans qu'il ne soit nécessaire que le dispositif électronique utilisateur communique avec le dispositif électronique certificateur (il peut le cas échéant exister des communications entre ces dispositifs, mais elles n'ont besoin de révéler aucune information sur les attributs stockés dans le dispositif utilisateur). De même, selon un mode de réalisation, le contrôle ultérieur par le dispositif électronique vérifieur du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur ne nécessite pas que le dispositif électronique vérifieur communique avec le dispositif électronique certificateur. Ainsi, le dispositif électronique certificateur, même s'il est amené à communiquer avec le dispositif électronique vérifieur, n'acquiert aucune information sur les attributs. Par exemple, la mairie n'est pas informée (et ne peut déduire des informations collectées) que telle ou telle personne est allée au cinéma à telle ou telle date et à telle ou telle heure. Selon un mode de réalisation possible, le procédé empêche la mairie de récupérer (par exemple via son dispositif électronique certificateur) des informations susceptibles d'identifier l'utilisateur, non seulement par l'absence de communication entre le dispositif électronique certificateur et d'une part le dispositif électronique utilisateur, d'autre part le dispositif électronique vérifieur, mais également par le protocole mis en oeuvre par le procédé. Ce protocole peut empêcher le dispositif électronique certificateur d'établir un lien entre une demande d'autorisation d'accès par un dispositif électronique utilisateur (et/ou le traitement de cette demande d'accès par un dispositif électronique vérifieur) et des informations identifiant un dispositif électronique utilisateur particulier. Selon une variante possible, le dispositif électronique certificateur peut être amené à intervenir lors de la requête d'accès par le dispositif électronique utilisateur et de son traitement par le dispositif électronique vérifieur. Le protocole mis en oeuvre peut alors empêcher le dispositif électronique certificateur de déduire, à partir des informations auxquelles il est amené à accéder, des informations d'identification de l'utilisateur. En particulier, selon un mode de réalisation, le procédé met en oeuvre un protocole empêchant d'établir un lien entre la signature émise par le dispositif électronique certificateur et celle qui est déterminée par le dispositif électronique utilisateur à partir de cette précédente signature. Ce procédé est avantageux en ce qu'il permet de préserver l'anonymat (en ne divulguant pas tous les attributs mais seulement ceux qui sont nécessaires), tout en préservant l'authentification (le dispositif électronique utilisateur prouve qu'il détient bien les attributs critiques pour l'accès au service). Ce procédé est également avantageux en ce qu'il permet d'empêcher le dispositif électronique utilisateur de modifier les attributs protégés autrement qu'en les effaçant (ainsi, il ne peut pas, par exemple, remplacer un nom de famille par un autre), et en ce que le dispositif électronique utilisateur ne peut effacer que les attributs autorisés (il peut lui être interdit d'effacer certains attributs). Le procédé permet également d'empêcher un dispositif électronique utilisateur de partager ses attributs avec d'autres. A cette fin, il peut être prévu que la clé de modification ne puisse pas être extraite du dispositif électronique utilisateur. Par exemple, dans le cas où ledit dispositif est une carte à puce conforme au standard ISO 7816-4, la clé de modification peut être stockée dans un fichier tel qu'un fichier de type EF (elementary file au sens de la norme ISO précitée). Ce fichier EF peut être protégé en lecture, mais accessible à l'OS (système d'exploitation) de la carte à puce (ou à une application telle qu'un softmask ou une applet javacard). Ainsi, la clé de modification peut être utilisée par le dispositif électronique utilisateur lui-même (à l'aide par exemple des fonctions prédéfinies qu'il embarque dans son système d'exploitation sécurisé), mais pas extrait (une commande de type READ_BINARY définie par l'ISO renvoyant un code d'erreur puisque l'accès en lecture est interdit). A l'aide de dispositions de ce type, un dispositif électronique utilisateur ne peut donc pas être frauduleusement combiné avec d'autres, afin de reconstituer une fausse identité (par exemple en combinant l'attribut FIRST_N d'un premier dispositif avec l'attribut LAST_N d'un deuxième dispositif et l'attribut BIRTH_D d'un troisième dispositif). Le procédé peut être mis en oeuvre à l'aide d'une suite d'instructions constituant un programme d'ordinateur exécuté par un processeur du dispositif électronique utilisateur. Mais il peut également être mis en oeuvre à l'aide d'un circuit électronique dédié intégré au dispositif électronique utilisateur, tel qu'un ASIC, un FPGA (ou les variantes PAL, EPLD, PLD, CPLD, PLA, etc.) convenablement configuré (par exemple en VHDL), voire de l'électronique dédiée conçue sur mesure. Selon un mode de réalisation, un procédé de contrôle d'accès est mis en oeuvre de façon à ce que la détermination de la signature de l'ensemble modifié soit opérée sans que le dispositif électronique utilisateur ne communique avec le dispositif électronique certificateur, afin de permettre le contrôle ultérieur, par le dispositif électronique vérifieur, sans que le dispositif électronique vérifieur ne communique avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. On évite ainsi toute communication avec le dispositif électronique certificateur lors de la tentative d'accès au service, ce qui élimine de facto tout risque de récupération d'informations par le dispositif électronique certificateur durant cette tentative d'accès. Selon un mode de réalisation, l'effacement d'attributs mis en oeuvre par le procédé de contrôle d'accès comprend le retrait des attributs à effacer de l'ensemble d'attributs. Ainsi, on peut par exemple recalculer que signature des seuls attributs date de naissance BIRTH_D et ville de résidence CITY, à l'exclusion des autres attributs. Si ces deux attributs occupent 20 octets chacun, on recalcule ainsi la signature d'un message de 40 octets seulement (à l'exclusion des octets alloués aux autres attributs). Selon un mode de réalisation, l'effacement d'attributs mis en oeuvre par le procédé de contrôle d'accès comprend le remplacement des attributs à effacer par des informations anonymes. Par exemple, le procédé peut remplacer les attributs à effacer par des caractères distingués (sans corrélation avec l'attribut à remplacer). Ainsi, l'attribut de nom de famille LAST_N, qui peut par exemple contenir la chaîne de caractères « DUCHESNES », peut-il être remplacé par l'une des chaînes « XXXXXXXXX », « » (chaîne constituée de caractères d'espacement), « », « ######### », ou encore « 777777777 », qui ne sont évidemment indiquées qu'à titre purement indicatif et non limitatif. Les attributs de remplacement peuvent avoir la même taille que les attributs d'origine (en nombre de bits). Dans cette hypothèse, les attributs peuvent avoir une taille prédéfinie indépendamment de leur contenu. Par exemple un attribut de nom de famille peut faire 35 caractères, indépendamment du nom de famille enregistré dans cet attribut (les noms sont alors supposés de longueur égale ou inférieure à 35 caractères, dans le cas contraire ils peuvent être tronqués à 35 caractères, ou à toute autre taille jugée opportune pour l'attribut considéré). Le nom de famille peut alors être enregistré indifféremment au début, au milieu, à la fin, ou en toute position du champ de 35 caractères réservés pour le nom de famille, les caractères non utilisés du champ pouvant être définis de façon conventionnelle (par exemple il peut s'agir de caractères d'espacement, tels que le caractère de code ASCII 32, soit 0x20). Alternativement, il est possible de transformer le contenu d'un attribut (par exemple une chaîne de caractères ASCII) en une série de bits (ne possédant pas nécessairement de représentation visuelle selon un jeu de caractères standard, tel que l'ASCII), la valeur des bits de la série de bits étant calculée afin de ne pas modifier le résultat d'une fonction de hachage caméléon appliquée à l'ensemble d'attributs. Selon un mode de réalisation, la fonction de signature électronique sanitisable du procédé de contrôle d'accès est une fonction de signature caviardable, ou une fonction de signature électronique couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique couplée à une fonction de noircissage. Les fonctions de signature caviardable sont des fonctions de signature électronique permettant de cacher certaines parties d'un message signé tout en gardant la signature valide. Elles peuvent s'appuyer sur la construction de certificats (sortes de cartes d'identité numérique) ayant des propriétés de caviardage (terme typographique désignant le fait d'ôter certaines parties d'un texte). Ainsi, par exemple, un étudiant peut cacher certains attributs de sa carte d'identité numérique sans la rendre inutilisable. Les fonctions de signature caviardable peuvent être une version simple des signatures sanitisables. Les fonctions de signature caviardable peuvent s'appuyer notamment sur un schéma de signature caméléon. Les fonctions de signature caviardable mises en oeuvre dans le procédé peuvent noircir les attributs à cacher (tous les attributs sauf les attributs requis pour l'accès au service) en les remplaçant par des caractères distingués, mais elles peuvent également être des fonctions de signature dite supprimable (de l'anglais deletable), où l'on supprime (retire) les attributs à cacher, sans les remplacer par quoi que ce soit (même des caractères distingués). Elles permettent seulement à une entité possédant la bonne trappe, de noircir ou supprimer certaines parties bien définies d'un message, de telle sorte qu'il ne soit en pratique pas possible de déterminer ces parties à partir des parties noircies (ou supprimées - il est clair que l'on ne peut pas déterminer une information à partir de rien). Noircir une information sensible signifie remplacer cette information (telle qu'un attribut que l'on n'est pas tenu de divulguer), par des informations non corrélées, ne divulguant aucune information sensible (par exemple des caractères distingués, tels que la chaîne de caractères « ##########M## »). En faisant signer un ensemble d'attributs par un dispositif électronique certificateur à l'aide d'une signature caviardable (éventuellement supprimable), et en donnant la trappe (la clé de modification) au dispositif électronique utilisateur, le dispositif électronique utilisateur est donc en mesure de noircir (ou de supprimer, suivant la technique utilisée) les attributs qu'il ne souhaite pas révéler, puis de modifier la signature de telle sorte qu'elle semble avoir été produite par le dispositif électronique certificateur. Le dispositif électronique utilisateur est ainsi, lors d'une demande d'accès à un service, anonyme vis-à-vis de l'extérieur (que ce soit vis-à-vis du dispositif électronique vérifieur, du dispositif électronique certificateur, ou de toute autre entité) et ne révèle au dispositif électronique vérifieur que les attributs demandés. Par ailleurs, dispositif électronique utilisateur n'est pas en mesure de modifier les attributs initialement signés par le dispositif électronique certificateur autrement qu'en les supprimant ou en les remplaçant par des informations « neutres » (ne correspondant à aucun attribut légitime du même type, tel que le nom d'une autre ville pour un attribut indiquant une ville) et ne peut donc pas tricher en se faisant passer pour un dispositif électronique utilisateur détenant des attributs différents. Selon un mode de réalisation, les attributs (par exemple les attributs BIRTH_D et CITY) requis pour l'accès anonyme au service dépendent dudit service, et le procédé comprend une détermination desdits attributs requis en fonction dudit service. Par exemple, le même dispositif électronique utilisateur peut permettre à son détenteur humain d' accéder à un cinéma mais également d' accéder à une piscine municipale. L'accès au cinéma avec un tarif réduit peut être subordonné à la présentation d'un attribut CITY autorisé. L' accès au cinéma pour voir des films réservés aux plus de 16 ans peut être subordonné à l'attribut BIRTH_D. Ces deux attributs peuvent donc constituer l'ensemble des attributs potentiellement modifiables. Selon un mode de réalisation, pour un accès à un cinéma, le dispositif électronique peut déterminer que seuls les attributs CITY et BIRTH_D sont susceptibles d'être requis. Le dispositif électronique utilisateur peut automatiquement effacer tous les attributs autres. Il peut alternativement laisser à l'utilisateur humain du dispositif électronique utilisateur l'opportunité d'effacer les attributs de son choix (les attributs peuvent correspondre à des attributs de l'utilisateur humain lui-même). Il peut être interdit à l'utilisateur humain d'effacer certains attributs, par exemple l'attribut BIRTH_D. Dans ce cas, la non-présentation (par effacement) de l'attribut CITY entraîne par exemple simplement l'absence de réduction, mais il n'est pas possible de ne pas présenter son âge (ceci n'est évidemment qu'un exemple, il serait possible que l' âge soit également effaçable). Selon un mode de réalisation, pour un accès à une piscine, les attributs peuvent être différents de ceux requis pour un accès au cinéma. Il peut par exemple y avoir un attribut indiquant la date du dernier certificat médical d'aptitude à la natation dument présenté à une autorité habilitée, et il peut être prévu que seul un détenteur authentifié d'un attribut indiquant une date de moins d'un an a le droit d'entrer dans la piscine. L'entité qui accède au service à l'aide du dispositif électronique utilisateur (par exemple une carte d'identité électronique) peut être un utilisateur humain du dispositif électronique utilisateur. Par exemple en entrant dans un cinéma, un utilisateur humain peut présenter sa carte d'identité à un lecteur NFC pour valider qu'il a le droit de voir un film en fonction des attributs de la carte d'identité. Cependant, le service peut également être fourni au dispositif électronique utilisateur. L'utilisateur humain peut alors accéder au service par l'intermédiaire du dispositif électronique. Par exemple, le dispositif électronique utilisateur peut être un téléphone portable, et le service peut être un service de vidéo à la demande, dans ce cas la vidéo est envoyée au téléphone portable (le service est donc fourni au dispositif électronique utilisateur), et l'utilisateur humain peut visualiser la vidéo sur son téléphone portable. Pour certains services, l'utilisateur humain peut être amené à laisser son dispositif électronique utilisateur (carte d'identité, carte d'étudiant, etc.) à l'entrée, et à ne le récupérer qu'à la sortie (club de tir, bibliothèque réservée aux chercheurs et donnant accès à des ouvrages d'une valeur inestimable, visite d'un site classé confidentiel défense, etc.). Le dispositif électronique utilisateur pouvant également être un téléphone portable stockant les données personnelles requises pour l'accès (les attributs), l'accès peut être autorisé par le téléphone portable mais son utilisateur humain peut être obligé de laisser le téléphone portable à l'entrée ou de l'éteindre. Ce type de situations est également envisageable pour des dispositifs électroniques utilisateurs autres que des téléphones portables. Le dispositif électronique utilisateur peut contenir des informations personnelles imprimées (par exemple dans le cas d'une carte d'identité). Le dispositif électronique utilisateur peut contenir des informations imprimées se rapportant à des caractéristiques différentes des caractéristiques faisant l'objet des attributs stockés. Par exemple, la photo, les initiales, et le département dans lequel travaille un étudiant chercheur peuvent être imprimés sur sa carte d'étudiant, mais son nom complet, son adresse personnelle et sa date de naissance peuvent n'être disponibles que sous forme d'attributs enregistrés dans la puce de sa carte d'étudiant. Ceci est avantageux notamment dans le cas où le dispositif électronique utilisateur doit être laissé à l'entrée. Alternativement, le dispositif électronique utilisateur peut comprendre les mêmes informations sous forme d'attributs stockés et de données imprimées, mais peut être remis dans une consigne fermée en échange de la clé unique d'un cadenas de la consigne, ou encore, dans le cas d'une carte, être avalé par un lecteur de carte (à la manière d'un distributeur de billet), stocké à l'intérieur, et restitué sur présentation d'un identifiant et d'un code PIN de la carte (sans que personne d'autre que le titulaire n'ait l'opportunité de voir ce qui est imprimé sur la carte), après délivrance du service à l'utilisateur humain. Selon un mode de réalisation, le procédé de contrôle d'accès comprend la certification, par le dispositif électronique certificateur, de l'ensemble d'attributs à l'aide de la fonction de signature électronique sanitisable. Selon un mode de réalisation, le procédé de contrôle d'accès comprend le contrôle, par le dispositif électronique vérifieur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Selon un mode de réalisation, un dispositif électronique utilisateur ID_CARD est agencé pour stocker une clé de modification MOD_K ainsi qu'un ensemble certifié d'attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE, CSHIP. Le dispositif électronique utilisateur peut être une carte à puce, ce qui est avantageux pour la sécurité. Il peut s'agir d'une carte à puce quelconque, notamment d'une carte à contact (par exemple au standard ISO 7816-2), d'une carte sans contact (par exemple une carte au standard MiFare, au standard ISO 14443, ou encore comprenant une interface NFC quelconque), d'une carte mixte à contact et sans contact avec une puce commune aux deux interfaces ou bien avec une puce distincte pour chaque interface contact et sans contact, etc. La carte peut être au format ID-1 de l'ISO-7810, au format ID-000 de cette même norme (format dit « plug-in »), au format microSlM, ou à tout autre format adapté (il peut s'agir d'un document d'identité en papier au format d'un passeport conventionnel, etc.). La carte peut comprendre une puce de carte bancaire, de carte SIM (l'acronyme SIM, de l'anglais Subscriber Identity Module, désigne de façon générique toutes les variantes CSIM, USIM, UICC etc.), de carte PKI, de carte d'accès, de carte de santé, de carte de transport, de carte d'identité, de passeport, de chronotachygraphe, etc. En particulier, le dispositif électronique utilisateur peut être une carte SIM équipée d'un circuit électronique capable de gérer des communications sans fil de type NFC. Comme le format de petite taille d'une carte SIM rend difficile l'intégration d'une antenne, la carte SIM peut comprendre un contact conforme au standard SWP (Single Wire Protocol) permettant à la SIM de se raccorder à une antenne intégrée au téléphone portable et de fonctionner de façon autonome. Autrement dit, la carte peut fonctionner indépendamment du fait que le portable soit allumé ou éteint et que la batterie du téléphone portable soit chargée ou vide. La carte peut en effet être alimentée par le champ électromagnétique généré à cet effet par le lecteur NFC avec lequel elle entre en communication (un lecteur NFC intégré au dispositif électronique vérifieur, ou communiquant avec lui), via l'antenne NFC du téléphone portable. Ceci permet de mettre en place un environnement mieux contrôlé et plus sécurisé que celui du téléphone portable qui est souvent beaucoup plus complexe et ouvert (permettant le chargement d' applications tierces, et éventuellement de virus). Le dispositif électronique utilisateur peut également être une carte mémoire dotée d'un processeur (de type secureMMC, etc.), une clé USB, etc. Le dispositif électronique utilisateur peut également être un ordinateur quelconque. L'ensemble d'attributs stocké dans le dispositif électronique utilisateur est certifié par un dispositif électronique certificateur CERT_SRV à l'aide d'une fonction de signature électronique sanitisable. Ladite fonction est associée à une clé de signature SIG_K stockée dans ledit dispositif électronique certificateur ainsi qu' à ladite clé de modification MOD_K. Le dispositif électronique utilisateur est agencé pour modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs BIRTH_D et CITY requis pour l'accès anonyme audit service, et pour déterminer, à l'aide de la clé de modification, la signature de l'ensemble d'attributs modifié. Ceci permet le contrôle ultérieur, par un dispositif électronique vérifieur VERIF_PC (qui peut être un ordinateur de type PC, un serveur, un lecteur NFC comprenant un circuit pour communiquer avec le dispositif électronique utilisateur, etc.), du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour déterminer la signature de l'ensemble d'attributs modifié sans communiquer avec le dispositif électronique certificateur. Ceci permet le contrôle ultérieur, par le dispositif électronique vérifieur, sans que ce dispositif électronique vérifieur ne communique lui non plus avec le dispositif électronique certificateur, du fait que la signature électronique de l'ensemble modifié correspond à une signature valide du dispositif électronique certificateur. Le dispositif électronique certificateur n'étant a aucun moment impliqué dans la requête d'accès par le dispositif électronique utilisateur ni le traitement de cette requête par le dispositif électronique vérifieur, ce dispositif électronique certificateur ne peut matériellement collecter aucune information sur le dispositif électronique utilisateur (et sur son détenteur humain) à l'occasion de cette transaction (et ce que la transaction aboutisse ou non à une approbation de l' accès). Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en retirant lesdits attributs à effacer de l'ensemble d'attributs. Selon un mode de réalisation, un dispositif électronique utilisateur est agencé pour effacer les attributs autres que les attributs requis pour l'accès anonyme audit service en remplaçant lesdits attributs à effacer par des informations anonymes. Selon un mode de réalisation, la fonction de signature électronique sanitisable d'un dispositif électronique utilisateur est de l'un des types suivants: une fonction de signature caviardable, ou une fonction de signature électronique conventionnelle couplée à une fonction de hachage caméléon, ou encore une fonction de signature électronique conventionnelle couplée à une fonction de noircissage. Selon un mode de réalisation, les attributs (par exemple BIRTH_D et CITY) requis pour l'accès anonyme au service dépendent dudit service, le dispositif électronique utilisateur étant agencé pour déterminer lesdits attributs requis en fonction dudit service. Selon un mode de réalisation, un système de contrôle d' accès anonyme à un service comprend un dispositif électronique utilisateur selon un mode de réalisation, et au moins l'un des deux dispositifs suivants: - un dispositif électronique certificateur CERT_SRV agencé pour certifier un ensemble d'attributs FIRST_N, LAST_N, BIRTH_D, BIRTH_P, ADDR, CITY, STATE et CSHIP à l'aide d'une fonction de signature électronique sanitisable, ladite fonction étant associée à une clé de signature stockée dans le dispositif électronique certificateur ainsi qu'à une clé de modification, de manière à permettre au dispositif électronique utilisateur, lorsqu'il a préalablement stocké l'ensemble d'attributs certifié ainsi que la clé de modification, de modifier l'ensemble d'attributs en effaçant des attributs autres que les attributs BIRTH_D et CITY requis pour l' accès anonyme audit service, et de déterminer, à l'aide de la clé de modification, la signature de l'ensemble modifié, - un dispositif électronique vérifieur VERIF_PC agencé pour recevoir du dispositif électronique utilisateur un ensemble certifié d'attributs BIRTH_D, CITY, et pour contrôler que la signature électronique de l'ensemble reçu correspond à une signature valide d'un dispositif électronique certificateur CERT_SRV. Le dispositif électronique utilisateur peut être agencé pour communiquer avec le dispositif électronique certificateur via un réseau filaire ou sans fil (par exemple de type Ethernet, WiFi, ATM, ADSL, satellite, Wimax, réseaux cellulaires 1G, 2G, 3G, 4G etc.), éventuellement par l'intermédiaire d'un hôte (par exemple un ordinateur personnel ou un téléphone portable auquel on connecte le dispositif électronique utilisateur). Le dispositif électronique vérifieur peut également être agencé pour communiquer avec le dispositif électronique certificateur via un réseau filaire ou sans fil (par exemple de type Ethernet, Wi-Fi, ATM, ADSL, satellite, Wimax, réseaux cellulaires 1G, 2G, 3G, 4G etc.). Cependant, dans le cadre d'une transaction d'autorisation d'accès, le dispositif électronique utilisateur et le dispositif électronique vérifieur peuvent être agencés pour ne communiquer ni l'un ni l'autre avec le dispositif électronique certificateur. Le dispositif électronique utilisateur et le dispositif électronique vérifieur peuvent être agencés pour communiquer entre eux à l'aide de protocoles filaires ou sans fil qui peuvent être des protocoles à courte portée (ZigBee, Bluetooth, infrarouge tel que l'irDA, connexion USB, connexion FireWire - IEEE 1394, connexion Sata ou eSata, connexion CPL, connexion Wireless USB, connexion propriétaire, ISO 7816, ISO 14443A ou ISO 14443B, Wi-Fi, etc.). Le dispositif électronique certificateur peut comprendre des éléments de redondance, par exemple des disques durs ou des mémoires protégées selon une technique RAID (pour redundant array of independent disks) bien connue, protégeant ainsi contre la perte de la clé de signature sans pour autant imposer de stockage de cette clé hors du dispositif électronique certificateur. Selon un mode de réalisation, un programme d'ordinateur est agencé pour mettre en oeuvre un procédé selon un mode de réalisation lorsqu'il est exécuté par un processeur. Le processeur peut être un processeur du dispositif électronique utilisateur, ou un processeur d'un module de sécurité inséré dans un tel dispositif (par exemple un processeur de carte à puce SIM insérée dans un téléphone portable). Le programme d'ordinateur peut être écrit en langage C, en Java, en C++, en C#, en Basic (et ses multiples variantes), en assembleur, ou en tout langage approprié. Le programme d'ordinateur peut comprendre des instructions adaptées pour tirer partie d'un support matériel dédié du processeur, tel qu'un cryptoprocesseur permettant d'accélérer certains calculs (tels que des exponentiations modulaires) qui sinon peuvent être plus lents à mettre en oeuvre sur la seule base d'un jeu d'instruction standard de processeur conventionnel. Selon un mode de réalisation, un support de stockage non transitoire lisible par ordinateur stocke un programme selon un mode de réalisation possible. Le support de stockage peut être par exemple une carte à puce, une clé USB, un microcontrôleur doté d'une mémoire non volatile (EEPROM, Flash, ROM, etc.), une puce mémoire, une carte mémoire, un support de stockage magnétique (disque dur, bande magnétique, disquette, etc.), ou tout autre forme de stockage adaptée. Des modes de réalisation spécifiques particulièrement avantageux sont décrits plus précisément ci-après. Les participants d'un système d'accréditation anonyme sont des organisations (disposant de dispositifs électroniques certificateurs), des utilisateurs (disposant de dispositifs électroniques certificateurs), et des vérifieurs (disposant de dispositifs électroniques vérifieurs). Les organisations délivrent des accréditations (par exemple des attributs certifiés) aux utilisateurs, qui peuvent les utiliser de manière anonymes auprès de vérifieurs (par exemple des fournisseur de services). Un système d'accréditation anonyme peut mettre en oeuvre les fonctions suivantes. AC:Setup : La fonction AC:Setup a pour but de générer les paramètres du système. Elle prend en entrée un paramètre de sécurité (qui peut correspondre à la taille des éléments cryptographiques à manipuler) et retourne les paramètres param (éléments d'un groupe et scalaires qui sont publics). AC:OrgKeyGen, AC:UserKeyGen : Les fonctions OrgKeyGen et UserKeyGen génèrent des clefs (secrètes et/ou publiques) pour, respectivement, les organisations et les utilisateurs. AC: Obtain AC:Issue. Ces deux fonctions forment un protocole exécuté entre un utilisateur souhaitant obtenir une accréditation et une organisation délivrant des accréditations. La fonction Obtain, exécutée par l'utilisateur, prend en entrée une clef secrète skU et une clef publique d'organisation pkO. La fonction Issue, exécutée par l'organisation, prend en entrée une clef secrète d'organisation skO, une donnée publique utilisateur pkU et une liste d'attributs (nom, date de naissance, étude, etc.) qu'elle souhaite certifier à l'utilisateur A la fin du protocole, l'utilisateur U a obtenu une accréditation C (ou bien un message d'erreur a été généré). C OBTAIN(sku, pko) IssnE(sk0. pki n t'Y-1 ) La double flèche symbolise les interactions entre les différents programmes qui s'exécutent et les flèches indiquent les sorties des fonctions. AC:Show r AC:Verify. Ces deux fonctions forment un protocole exécuté entre un utilisateur souhaitant justifier la possession d'une accréditation et un vérifieur souhaitant vérifier cette possession. La fonction Show, exécutée par l'utilisateur, prend en entrée une clef secrète skU, une clef N publique pkO, une liste de messages {Mn n =1 et une accréditation C. La fonction Verify, exécutée par N le vérifieur, prend en entrée une clef publique pkO et une liste M de messages telle que M C {mn }n_1 A la fin du protocole, la fonction Verify retourne un bit b {O' 1 indiquant s'il accepte la preuve de possession de l'utilisateur. Pko, Int VERIEY(pko, b Le protocole de vérification est public: il ne nécessite pas de clef secrète pour être exécuté. Les notations suivantes sont utilisées. e {0 1} , Un message m est, génériquement, une chaîne de bits de longueur (c, est-a-dire une suite de bits 0 ou 1, de longueur arbitraire comme l'indique l'étoile *). On sépare les messages en blocs m := * * , où N est le nombre de blocs et 11 un symbole de concaténation. Les portions de message que l'utilisateur pourra modifier, ou supprimer selon les cas, sont AD C {1 11 désignées par un sous-ensemble d'indice m . La partie fixe x d'un message = d'après un ensemble de portions admissibles ADM est donnée par la fonction 1:1X,ADm M H 11-1 où { := {1, _ , \ ADM admissibles (c'est-à-dire modifiables) ADM pour un message 111 := une liste de paires d'indices et de messages (ou blocs) , sont données par (c'est-à-dire Les instructions de modification MOD, étant donnée une assignation de portions que le bloc modifié m'i a la même taille, en nombre de bits, que le bloc mi d'origine), pour tout J e ADm. Ces instructions dénotent le fait que le jème bloc de message mi doit être remplacé par le nouveau bloc m'i. Dans le cas des signatures caviardables, une instruction de modification ?r'?) devient devient ' le symbole t (« bot », de l'anglais bottom) indiquant que le jème bloc de message doit être noirci ou supprimé. La notation m°D - m indique que les instructions de modification MOD sont compatibles avec les portions admissibles ADM. C'est-à-dire que ces instructions ne demandent pas de modifier un bloc qui n'a pas été désigné comme modifiable. On note = ,MOD le message instructions de modification MOD. moDo ) et Soit ADM des portions admissibles et u; \1(11) deux messages accompagnés résultant de la sanitisation du message m selon les d'instructions de modification. Si les messages sont identiques une fois que la sanitisation a été appliquée, alors on note 1=1 D0. ADM) 1.1m . MOD ) La notation { 1=-1 indique qu'il existe un sous-ensemble d'indices _i C {1 }tel que filin' r pour tout c {1.... N'} Dans un schéma de signature sanitisable, noté SAN, deux types de participants sont présents: les signeurs et les sanitiseurs. Un schéma de signature sanitisable est donné par les cinq fonctions suivantes. SAN:Setup. La fonction Setup génère les paramètres du système. Elle prend en entrée un paramètre de sécurité (qui correspond à la taille des éléments cryptographiques à manipuler) et retourne les paramètres param (éléments d'un groupe et scalaires qui sont publics). SAN:SigKeyGen, SAN:SanKeyGen. Les fonctions SigKeyGen et SanKeyGen génèrent des clefs pour, respectivement, les signeurs et les sanitiseurs. SAN:Sign. La fonction de signature Sign prend en entrée une clef secrète sksig, un sanitiseur désigné par l'indice à qui il souhaite déléguer le droit de modifier le message, un message m et des portions admissibles ADM. Il génère une signature (ou un message d'erreur I , utilisant la même notation que pour la fonction de noircissage / suppression mais il s'agit ici d'une notion différente). SI( ;NI:sk,ig. SAN: S anitize. La fonction de sanitisation Sanitize prend en entrée une clef secrète de sanitiseur sksan, la clef publique du signeur plcsig, le message m, la signature et des modifications d'instructions MOD. Elle génère un message rrit et une signature sur ce message (ou un message d'erreur I ). -- S ['ri!-:isk.,~~ SAN: Verify. La fonction de vérification Verify prend en entrée la clef publique du signeur plcsig, le message m et la signature . Elle retourne un bit d'acceptation h e {(111 indiquant si la signature est valide ou non. La procédure de vérification est publique: elle ne nécessite pas de clef secrète pour être exécutée. Il existe différentes versions de signatures sanitisables. Les propriétés fonctionnelles et de sécurité de ces différentes versions varient selon les versions. Dans le cadre des modes réalisations décrits ci- dessous, le procédé s'appuie sur des signatures sanitisables remplissant les conditions suivantes. D'autres propriétés pourraient être ajoutées, mais ne sont pas indispensables. Il s'agit de conditions nécessaires pour obtenir les propriétés recherchées pour les accréditations anonymes dans le cadre de ces modes de réalisation (bien sûr, d' autres modes de réalisation moins sécurisés sont envisageables). Pl A La vérification d'une signature ne doit pas nécessiter la clé publique du sanitiseur qui a le droit de modifier le couple message/signature que l'on a. Ceci nous permet d'obtenir l'anonymat du sanitiseur (et donc de l'utilisateur dans notre système d'accréditations). En effet, même si la clé publique n'était pas liée à un individu formellement identifié, le simple fait qu'elle existe permettrait au minimum de suivre les transactions de l'utilisateur associé à cette clé publique, et pour peu que l'une des transactions révèle son identité, il serait éventuellement possible de lui associer toutes les transactions correspondantes. P1B Alternativement, la clé du sanitiseur est nécessaire, mais elle est cachée au moment de la vérification. A cette fin, le procédé s'appuie sur une preuve à divulgation nulle de connaissance (preuve dite « zero-knowledge ») pour cacher la clé du sanitiseur, tout en prouvant que la signature obtenue est valide. P2 L'utilisateur/sanitiseur ne doit pas être capable de remplacer l'un de ses attributs par quelque chose qui l'arrange (par exemple remplacer sa véritable ville de résidence par celle dont il souhaite profiter des services). En pratique, le sanitiseur ne doit pas être capable de remplacer une partie admissible d'un message signé par ce qu'il veut. Il faut par conséquent un système qui limite les modifications que peut apporter le sanitiseur. P3 Si un message initialement signé est modifié deux fois de la même façon par le même sanitiseur, cela doit être fait de façon non traçable: on ne doit pas savoir qu'il s'agit de la même entité. P4 Le rejeu d'une signature sanitisée doit être infaisable. Cette phase doit contenir un aléa maîtrisé à la fois par le sanitiseur et le vérifieur. L'obtention d'une accréditation peut s'effectuer selon le schéma suivant : pko) pku,Ift kin Ornaiii--;tt:o:t nz = rr Sw41V.Sïc (skrl.' .,, ..,;.,-I 1 t 1-11,.1- L'utilisation d'une accréditation peut, quant à elle, obéir au schéma suivant : Un système d'accréditation anonyme AC selon un mode de réalisation s'appuie sur un schéma de signature sanitisable SAN respectant les propriétés P1 A ou P1B, ainsi que P2 à P4, énoncées ci-dessus. La procédure AC:Setup de génération des paramètres du système d'accréditation anonyme est la procédure SAN:Setup de génération des paramètres du schéma de signature sanitisable. La procédure AC:UserKeyGen de génération des clefs des utilisateurs du système d'accréditation anonyme est la procédure SAN:SanKeyGen de génération des clefs des sanitiseurs du schéma de signature sanitisable. La procédure AC:OrgKeyGen de génération des clefs des organisations du système d'accréditation anonyme est la procédure SAN:SigKeyGen de génération des clefs des signeurs du schéma de signature sanitisable. Le protocole AC:Obtain AC:Issue d'obtention d'une accréditation anonyme par un utilisateur est exécuté de la manière suivante. Supposons que le document à signer m - 11* soit de longueur t (t bits), l'organisation O sépare m en N blocs de longueurs respectives { " r+.=r et spécifie un sous-ensemble d'indices { N} à sa convenance. Un champ spécifique, d'indice n, est choisi. L'organisation O génère alors une signature U := SAN:Sign(sko; pku; m; ADM) à l'aide de la clef publique pku de l'utilisateur U et envoie la signature à U. L'utilisateur U enregistre rr comme une accréditation de O sur le message m. Le document à accréditer peut correspondre à une concaténation des noms (ou identifiants) des champs (par exemple LAST_N, ADDR, etc.) et à la valeur de chacun de ces champs dans le cas d'espèce considéré (par exemple « Lescuyer », « Caen », etc.). Les parties admissibles peuvent correspondre aux valeurs des champs, et exclure les identifiants des champs (dans cette hypothèse, l'utilisateur ne doit pas pouvoir modifier LAST_N mais doit pouvoir modifier « Lescuyer », du moins il doit pouvoir le modifier d'une manière autorisée). La clé publique de l'utilisateur qui obtient l'accréditation correspond à sa clé publique de sanitiseur. Le protocole AC:Show ++ AC:Verify d'utilisation d'une accréditation par un utilisateur U auprès d'un vérifieur V peut être exécuté de la manière suivante. pko. C.\ 'k '1^ 111-,.atClii." } moD .= -{( ri A U' Am: A tt! (pk mi , SA., Supposons qu'un vérifieur V souhaite vérifier qu'un utilisateur U possède une accréditation certifiant la possession d'un ensemble d'attributs M. Supposons que l'utilisateur U possède une accréditation sur un document 111''-\- tel que M C 72=1 (c'est-à-dire que le document m possède les attributs demandés). Dans un premier temps, le vérifieur envoie une valeur aléatoire r à l'utilisateur U. Cette valeur r peut être par exemple la concaténation de données propres à la vérification et à l'heure courante. Dans un second temps, l'utilisateur U sanitise le document selon les instructions de modification suivantes 1VIOD {(n.r)} U {(n'. 1) n A n' E ADM. A et calcule e) va (T s pko, ,do1)) L'utilisateur envoie au vérifieur. Le vérifieur vérifie que la signature (71 est une signature valide de message grâce à la clef publique de l'organisation O. Il renvoie 1 si c'est le cas et 0 sinon. Un mode de réalisation est décrit plus précisément ci-dessous dans le cas d'une fonction de sanitisation particulièrement avantageuse. Ce mode de réalisation s'applique à des documents quelconques. Un document peut être défini - . comme une chaîne quelconque de bits. L'espace des messages est donc {0, 11Cependant, tous les documents à signer comportent un champ réservé de longueur fixe 1n. Ce mode de réalisation s'appuie sur une fonction de hachage qui permet de hacher uniformément dans 10,111" Selon ce mode de réalisation, les blocs de messages à noircir sont noircis d'une façon unique. Un bloc de longueur est toujours remplacé par un bloc de même taille. Le noircissage d'un bloc n peut par exemple consister en un remplacement de ce bloc par une suite de bits 0 de même longueur que ce bloc. Ce mode de réalisation se place dans le cadre d'un environnement bilinéaire symétrique pour effectuer les calculs. Dans p est un nombre premier, T sont des groupes algébriques d'ordre p, et e est une application bilinéaire` :GxG . Il existe de nombreux algorithmes bien connus pour générer de tels environnements de calcul. Les actions suivantes sont mises en oeuvre afin de créer un environnement de calcul global pour le système : 1. Générer un environnement bilinéaire symétrique 2. Choisir des générateurs désignant un choix opéré de façon aléatoire) G (le signe $ au dessus de la flèche 3. Choisir deux fonctions de hachage / '.)-1.1 TL) 1} zp 4. Retourner les paramètres du système para rn := Le signeur génère ses clefs en mettant en oeuvre les actions suivantes: 1. Choisir deux aléas Zp 2. Calculer := 3. Choisir une clef pour une fonction pseudo-aléatoire l Le protocole permettant à l'utilisateur d'utiliser une accréditation afin d'obtenir un accès à un service auprès d'un fournisseur de service que l'on appellera le vérifieur est décrit ci-dessous. L'accréditation ripeut avoir été délivrée sur un message trpar l'organisation identifiée par Pk'ig = Y" LI) selon les modalités précitées. L'utilisateur possède un certificat certsan = - La signature 0-est de la forme : O:2 i(Bn:1, n E .14,1 L'utilisateur souhaite cacher un sous-ensemble d'attributs M t=- / du document Ji où Ai est le sous-ensemble d'indices des blocs de messages que l'utilisateur à le droit de noircir. On désigne par In' le document In dans lequel chaque portion nii pour ieMa été noircie. Dans un premier temps, le vérifieur envoie à l'utilisateur une valeur aléatoire 7i.° (pour laquelle In un champ réservé est prévu). On peut, par exemple, hacher dans {0. 1} la concaténation de données liées au fournisseur de service et la date courante. Dans un second temps, l'utilisateur exécute les actions suivantes : IMI 1. Générer - + 6 aléas fi ff .:s1,..1\ I. 2. Hacher le message el IN 3. Pour tout e M, exécuter les actions suivantes : (a) Hacher 1 7-11 ( II Y II il / (b) Calculer 13e 4. Calculer : Bre:1 - Briz :2 5. Hacher le message : 6. Calculer : := ri C2 st := (2 rt, se, :=r i ° t (f2 := fr, r2 + 1, ml n T' , 'S"lb A DM) 7. Poser : := (Co Co, . L'utilisateur envoie alors et cel au vérifieur. Dans un troisième temps, le vérifieur, ayant reçu des données de la forme : 56, ADM)), B/0:2° 13. B1.2 R. et, exécute les actions suivantes: 1. Hacher le message 2. Hacher le message : 7-12 (CF.:1 ILI :,21 ;j'II-111 I où 3. Récupérer 111 présent dans ADM et poser 11,11 := les actions suivantes: (a) Si la portion puis, pour tout n i , mettre en oeuvre est différente de la partie noire, alors i. Si (Bn:1 Bn:2) , arrêter l'algorithme et retourner 0, sinon, continuer. ii. Mettre à jour M' U {n} iii. Hacher hn (-VIII'igPHN 4. Tester les équations suivantes : Si toutes ces équations sont vérifiées, le vérifieur retourne 1, sinon, il retourne O. Bien entendu, les exemples donnés ci-dessus ne sont nullement limitatifs. Les modes de réalisation concernant les procédés peuvent être transposés aux dispositifs, et réciproquement. Pour tout E M', e