Les signatures à l'aveugle

IV.3.1 Contribution de Chaum . . . 97

IV.3.2 Contribution de Brands . . . 99

IV.3.3 Contribution de Camenisch . . . 103

IV.4 Bilan . . . 109

IV.4.1 Certicats . . . 109

IV.4.2 Systèmes à pseudonymes . . . 111

IV.4.3 Révocation de l'anonymat . . . 111

IV.4.4 Non-transférabilité . . . 112

IV.4.5 Recouvrement et portabilité . . . 115

IV.4.6 Conclusion . . . 115

IV.5 Mise en ÷uvre . . . 116

IV.5.1 Librairie . . . 116

IV.5.2 Notes d'implémentation . . . 116

IV.5.2.1 API OpenSSL . . . . . . . 116

IV.5.2.2 Génération de résidus quadratiques . . . . 116

IV.5.2.3 Génération des paramètres RSA . . . . 117

IV.5.2.4 Exponentiation RSA . . . . . . 118

81 Dans la théorie des nombres, un problème est aussi immortel qu'une oeuvre d'art.

David Hilbert, Introduction aux Eléments de la théorie des nombres algèbriques de Legh Wilber Reid.

IV.1 Systèmes à pseudonymes

N

ous avons soulevé à plusieurs reprises les fonctionnalités et propriétés attendues du système de négociation. Nous reprenons ici celles qui ont trait aux besoins en pri-mitives cryptographiques. Dans un second temps, les diérentes propositions scientiques sont étudiées an de déterminer les plus pertinentes.

Au cours de la section II.1.4, nous indiquions que pour satisfaire aux conditions d'anony-mat, le système devait permettre d'échanger des certicats de sorte que :

 de multiples négociations sur un même fournisseur soient non associables si aucune identité n'y est établie, et ce même en présentant plusieurs fois un même certicat,  sous le couvert du pseudonymat, les transactions soient non associables entre tiers

an que de multiples identités d'une même entité ne le soient pas non plus.

Il s'agit donc de permettre l'inassociativité des transactions et de mettre en ÷uvre le statut d'anonymat ou de pseudonymat si l'établissement d'une identité est requis.

Une architecture permettant l'échange de certicats en satisfaisant la propriété de non associativité des identités est couramment appelée  système à certicats anonymes  ou  système à pseudonymes  (Lysyanskaya et al., 2000 ; Pashalidis & Mitchell, 2004). Les pseudonymes ont trait à l'établissement de l'identité et sont une condition à l'inassociati-vité des transactions lorsque l'établissement d'une identité est requis. Les pré-requis d'une telle architecture sont introduits par (Chaum, 1981).

Le principe de l'utilisation de multiples certicats numériques non associables présen-tés sous divers pseudonymes est introduit par (Chaum, 1985 ; Chaum & Evertse, 1987). Diverses briques ont été proposées (Chaum, 1983 ; Chaum et al., 1990 ; Chaum, 1991 ; Damgård, 1990 ; Brands, 1993, 1994, 1995 ; Chen, 1995) pour enn voir présentés des systèmes plus complets (Lysyanskaya et al., 2000 ; Brands, 2000 ; Camenisch & Lysyanskaya, 2001). Le c÷ur de l'architecture repose sur les certicats et sur leurs pro-priétés, c'est-à-dire sur le schéma de signature des certicats.

Nous décrivons dans cette section les dicultés techniques, architecturales et d'accep-tabilité que soulève une telle architecture.

IV.1.1 Les certicats

L'inassociativité des transactions suppose un schéma de signature des certicats permet-tant cette propriété. Plus précisément, ce qui est attendu, c'est un schéma de signatures

IV.1. Systèmes à pseudonymes 83 permettant de vérier la validité d'une signature sans que sa génération et sa vérication puissent être associées. Il est également nécessaire que ce schéma permette que les mul-tiples vérications d'une même signature soient inassociables. Les vérications d'un même certicat par une même entité, ou par de multiples entités, sont ainsi non-associables. Lorsque des certicats ont cette propriété, ils sont abusivement appelés certicats ano-nymes.

Le certicat est un ensemble d'informations et une signature de cet ensemble. Lorsqu'il s'agit d'un certicat d'identité, l'information est un ensemble d'attributs portant sur un sujet ou sur les propriétés du certicat. Une des fonctionnalités majeures attendues des certicats est la présentation sélective1 de certaines informations qu'ils contiennent. Le schéma de signature doit donc permettre de vérier la signature en présentant indépen-damment chacun des attributs, sous-ensemble de l'information signée. La signature n'est donc pas une donnée constante mais une donnée variable selon le contenu présenté lors de la vérication.

Les certicats et les protocoles de vérication représentent l'opportunité d'implémenter des mécanismes de preuves. Cela permet d'apporter la preuve de possession d'une signa-ture d'un générateur sans divulguer les données signées. En outre, en règle générale, la possession d'un certicat devrait toujours être prouvée, rendant le certicat assimilable à une clé publique que l'on prouve à l'aide d'une ou plusieurs clés privées. Il est ainsi pos-sible de prouver la possession d'un certicat, voir l'appartenance à un ensemble lorsque le générateur représente cet ensemble, sans avoir à présenter le contenu du certicat. Il est également souhaité que le schéma de signature permette de prouver des proprié-tés sur les informations signées. Donnons par exemple l'âge prouvé à partir d'une date de naissance chirée dans l'un des attributs contenus dans un certicat. Les preuves qu'il est possible d'apporter ont trait à des expressions numériques qui dans cet exemple serait :  date actuelle - date de naissance = âge . Il est donc important de raisonner en termes de données numériques pour savoir ce qu'il est possible de prouver. Les données qui sont prouvées sont généralement appelées engagements2.

Une partie des attributs contenus dans un certicat sert à dénir les propriétés du certi-cat. Il s'agit notamment des propriétés de validité. Un certicat peut être généré pour une durée de validité illimitée. Dans le cas contraire, il lui est associé une date d'échéance dont peut être déduite la durée de validité. Un certicat peut également être révoqué. La propriété de non-associativité empêche cependant de gérer une liste de révocation des

1. trad. Selective disclosure. 2. trad. Commitments.

certicats révoqués puisque le générateur ne peut pas désigner les certicats qu'il a émis aux consommateurs des certicats. Nous verrons que des solutions existent. Les certicats peuvent également être limités en nombre d'utilisations. Avec un certicat n'ayant pas la propriété de non-associativité une vérication auprès du générateur lors de sa présen-tation permet au générateur de compter le nombre d'utilisations, donc d'indiquer si un certicat est toujours valide. Les certicats anonymes supposent que chaque présentation de signature laisse une  trace  diérente, ce qui empêche ce procédé. Il existe cependant des mécanismes permettant de  libérer  un identiant du certicat dès qu'une utilisa-tion de celui-ci est faite au-delà du nombre permis. Il est également possible de coupler ces mécanismes avec un environnement utilisateur contrôlé à l'aide d'une plateforme de conance3. Les certicats sont présentés par l'intermédiaire de la plateforme de conance, plateforme qui a la charge de garantir le nombre de présentations autorisées. Il est éga-lement nécessaire que l'environnement client puisse aider l'utilisateur à gérer la validité de ses certicats, c'est-à-dire leur durée de validité et leur nombre d'utilisations. Cela est d'autant plus important si des moyens répressifs sont employés envers l'utilisateur en cas de mauvaise utilisation.

IV.1.2 Systèmes à pseudonymes

Un pseudonyme est un identiant d'une identité qui n'est pas associable à l'identité réelle d'une entité comme le dénit (Ptzmann & Kohntopp, 2001). L'établissement d'une iden-tité sous un pseudonyme est appelé  pseudonymat . Le pseudonymat se réduit le plus souvent à l'utilisation de pseudonymes. Nous y attachons l'idée de pseudonymes indis-tinguables, c'est-à-dire qui ne peuvent être corrélés, an d'assurer la non-associativité des identités comme nous l'avons indiqué section II.1.4. Nous distinguons ainsi le pseu-donymat, où les pseudonymes employés sont indistinguables, du  pseudonymat  public lorsqu'un pseudonyme est employé avec plusieurs parties.

Le pseudonyme est le moyen de désigner une identité et d'établir une identité. Cela sup-pose un protocole permettant l'établissement d'un pseudonyme entre un utilisateur et une organisation qui génère une donnée privée pour le possesseur de l'identité. Cela suppose également qu'il soit dicile que deux entités puissent présenter un même pseudonyme. Le pseudonymat permet de rendre les multiples transactions avec un même interlocuteur associables, donc d'associer de multiples négociations, ou plus généralement, de multiples actions à une identité.

Le pseudonymat est donc requis pour bénécier de la propriété de non-associativité des identités lorsque l'établissement d'identités est requis auprès de plusieurs entités.

IV.1. Systèmes à pseudonymes 85

Enn, il est possible d'exploiter l'inassociativité des multiples vérications d'un même certicat pour permettre de mener des négociations anonymes. Pour cela, soit aucun pseu-donyme n'est employé, soit un pseupseu-donyme n'est jamais réutilisé. Cela n'empêche en rien d'associer à une négociation menée dans de telles conditions un mécanisme permettant de révoquer l'anonymat.

IV.1.3 Besoins de l'architecture

IV.1.3.1 Révocation de l'anonymat

L'un des intérêts majeurs d'un système à pseudonyme est l'anonymat par l'inassociativité. Pour autant, il est nécessaire de prévoir des  échappatoires  contrôlées permettant de révoquer cet anonymat. Au vue des concepts précédemment dénis, il est possible d'en-visager deux types de révocation de l'anonymat suivant la propriété d'anonymat remise en cause : l'inassociativité ou le pseudonymat. Les deux types de révocation sont ainsi (Camenisch & Lysyanskaya, 2001) :

 la révocation de l'inassociativité entre générateurs et consommateurs, aussi appelée révocation locale,

 la révocation du pseudonymat permettant de révéler un pointeur vers une identité civile, aussi appelée révocation globale.

Vient ensuite la notion événementielle signiant les circonstances de la révocation. Là encore, il existe deux possibilités :

 la révocation devient possible dès lors que l'utilisateur commet une action spécique, détectable par le système, et que nous appelons révocation synchrone,

 la révocation est possible indépendamment d'une action quelconque de l'utilisateur vis-à-vis du système. Il s'agit par exemple de déterminer qu'il y a eu une action frauduleuse de l'utilisateur, non-détectable par le système alié au premier cas. Il s'agit donc de permettre une révocation à  contre-coup . Nous qualions cette révocation d'asynchrone.

La révocation asynchrone est une problématique délicate qui nécessite une architecture particulière comme nous le verrons par la suite. Il est cependant possible, dès à présent, de noter qu'il s'agit d'une responsabilité importante qui devrait être répartie entre plusieurs organismes indépendants (police et justice par exemple).

IV.1.3.2 Non-transférabilité

La non-transférabilité est un paradigme majeur de l'identité numérique et qui par ailleurs n'est restreint ni à ce domaine, ni à celui des certicats. Comme nous l'évoquions à la section II.1.3, une entité emprunte une identité dès lors qu'elle est à même de fournir la preuve de cette identité. Il s'agit ici de la problématique de la transférabilité de la preuve de l'identité. Cette problématique existe également pour les certicats.

Il existe divers mécanismes qui visent à adresser cette problématique et que l'on peut clas-ser en deux catégories : ceux qui s'appuient sur la technologie et ceux qui s'appuient sur la psychologie. Les solutions technologiques sont par exemple les plateformes de conance. Elles ne constituent cependant pas une réponse susante lorsqu'il s'agit d'établir l'iden-tité d'une enl'iden-tité. En eet, rien n'empêche un individu de céder sa carte de paiement et de révéler son code d'accès par exemple. Les solutions psychologiques ont trait à la dissua-sion, ce que (Dwork et al., 1996) nomme l'auto-réglementation4. Il s'agit par exemple de mesures de répression. Dans le cas de cartes de paiements, il s'agit d'attribuer la respon-sabilité des actes à son possesseur légitime tant qu'il ne déclare pas la perte. Ce peut être également la mise en gage d'une somme d'argent. Son obtention serait basée sur le secret dont on veut dissuader la cession, donc céder ce dernier reviendrait à céder la somme d'argent mise en gage. Cependant, comme tout mécanisme basé sur la psychologie, son ecacité est variable. Cela fait appel à la rationalité des individus mais également à la conance, notamment dans le bénéciaire de la cession du secret. La conance est alors à mettre en balance avec la valeur du gage et les préjudices éventuels résultant de la ces-sion du gage. Il apparaît évident que ces deux types de mécanismes sont complémentaires. En résumé, nous sommes face à deux problématiques : la cession des certicats5 et la mise en commun de certicats par deux entités que l'on appelle le partage de certicats6. Assurer la première propriété implique de résoudre la seconde, alors que la réciproque n'est pas vrai. La seconde problématique, parfois appelée coalition en équipe7 (Came-nisch & Lysyanskaya, 2001), peut paraître de prime abord solvable techniquement de manière relativement aisée. Citons par exemple un identiant unique associé à une entité que chaque générateur de certicat aurait à charge de mettre dans les certicats. Cette solution ne satisfait cependant pas la propriété de non-associativité des certicats. Nous verrons donc qu'il existe un mécanisme permettant de mettre un secret dans chacun des certicats et permettant à l'utilisateur de prouver que ce secret est le même dans chacun des certicats, sans remettre en question la propriété de non-associativité. Cette solution

4. trad. Self-Policing 5. trad. Lending. 6. trad. Sharing. 7. team-up

IV.1. Systèmes à pseudonymes 87 débouche alors sur la problématique de non-transférabilité du secret.

Enn, il est nécessaire d'ajouter une dernière problématique. Il est souhaité que cer-tains certicats soient non-cessibles et que d'autres le soient (les tickets de cinéma ou de la monnaie par exemple). Ces certicats ne devraient donc pas contenir d'informations liées à une identité. Cependant, la diculté réside dans la responsabilité d'une action frauduleuse du fait que, de la même façon que dépenser de l'argent ne revient pas à ne plus avoir les certicats à disposition, céder un certicat ne signie pas ne plus en avoir la possession.

IV.1.3.3 Recouvrement, renouvellement et portabilité

La dernière nécessité architecturale est celle de la gestion du cycle des secrets, et notam-ment des pseudonymes. Si l'on imagine que les utilisateurs batissent leur vie numérique autour des pseudonymes, leur perte ou leur compromission peuvent être extrêmement préjudiciables.

La problématique de la perte implique de permettre à un individu d' externaliser  ses secrets sans  céder sa vie numérique  comme nous l'évoquions à la section III.4. Les solutions se rapprochent également des besoins de portabilité des secrets. Il est donc envisageable que l'une des solutions, à l'instar de celle de la révocation de l'anonymat asyn-chrone, repose sur des organismes indépendants (la préfecture et le notaire de l'usager par exemple). En eet, le recouvrement n'est réalisable que s'il est possible de dupliquer la base des secrets, et le dépositaire des clés8 devient une menace en tant qu' usurpateur  d'identités potentiel.

La problématique de la compromission née du fait que l'utilisateur a la responsabilité de ses pseudonymes. Il doit pouvoir détecter une telle compromission et le prouver en cas de litige. Il est également nécessaire qu'il puisse renouveler ses pseudonymes auprès des organisations où il les avait établis. Un mécanisme d'établissement d'identité  de secours  prenant l'ascendant sur celui fait à l'aide des pseudonymes est donc à prévoir.

IV.2 Bases

C

ette section présente les bases cryptographiques nécessaires à la compréhension de ce chapitre. Elles ne sont pas présentées aussi formellement que ce qu'il est coutume de rencontrer dans les travaux dédiés à ce sujet. Elles sont cependant présentées de manière intuitive et concise.

IV.2.1 Notation

Nous utiliserons par la suite les notations courantes suivantes :

 Lorsqu'il sera évoqué une valeur choisie aléatoirement dans un ensemble E, cela suppose une distribution de probabilité uniforme indépendante, notée x ∈_RE.  On note Zt l'anneau des entiers modulo t.

 On note Z∗

t son groupe multiplicatif. Le nombre d'éléments d'un groupe est appelé ordre du groupe.

 QRt est le groupe des résidus quadratiques modulo t.

 Le plus grand diviseur commun de a et de b égal à c est noté pgcd(a,b) = c. Si c = 1,

a et b sont dits co-premiers.

 Si a est un facteur de b on dit que a divise b noté a | b ou a div b. Si a ne divise pas b, on le note a - b

 akb, la concaténation de deux chaînes binaires.

 Soit H : {0,1}∗ −→ {0,1}l une fonction de hachage résistante aux collisions qui associe à une représentation binaire en argument une chaîne binaire de longueur l. Notons que nous utilisons à de multiples reprises des éléments mathématiques appelés  générateurs . Ce terme porte à confusion avec le terme générateur employé pour les gé-nérateurs de certicats. Ainsi, lorsque le mot générateur suppose l'élément mathématique, il est noté en italique.

IV.2.2 Problèmes cryptographiques

Soit une fonction f associant une valeur du domaine X à une valeur unique dans le co-domaine Y , notée f : X −→ Y . L'image y ∈ Y de x ∈ X est notée y = f(x). Une fonction cryptographique f est considérée comme étant à sens unique s'il est possible de considérer comme simple le calcul de f(x) à partir de x et dicile celui de x à partir de f(x). Il est attendu que les fonctions à sens uniques soient libres de collisions, c'est à dire que si

f (a) = f (b) alors a = b.

Les fonctions à sens unique constituent la base de nombre de primitives cryptographiques et de cryptosystèmes à clés publiques. Considérons une clé publique et une clé privée.

IV.2. Bases 89 La primitive de chirement consiste à utiliser une fonction à sens unique permettant de chirer une donnée à l'aide d'une clé publique et de ne rendre celle-ci déchirable qu'à l'aide de la clé privée. Il est donc possible de supposer que la fonction de chirement soit simple pour le chirement à l'aide de la clé publique et dicile pour le déchirement si l'on ne possède pas la clé privée.

La constitution de telles fonctions peut reposer sur des problèmes de la théorie des nombres considérés comme diciles. Cela suppose qu'ils soient solvables en des temps de calculs fonction de la taille des ensembles. Ainsi, en augmentant ces tailles, il est possible de rendre les problèmes susamment diciles à calculer pour les rendre utilisables pour des applications pratiques de fonctions à sens unique.

Les cryptosystèmes à clés publiques reposent sur des problèmes considérés comme dif-ciles bien que leur appartenance à cette classe n'ait pas été démontrée. Voici quelques exemples de problèmes employés par la suite (Menezes et al., 1996).

1. Le problème de la décomposition d'un entier positif n en facteurs premiers (FAC-TORING) : il est considéré comme dicile d'écrire n = pe1

1 ...p^ek

k où les pi sont des nombres premiers distincts et les ei des entiers positifs.

2. Le problème RSA (RSA) : il est considéré comme dicile de trouver un entier m tel que me ≡ c mod n avec n un entier positif produit de deux premiers p et q, e tel

que pgcd(e,(p − 1)(q − 1)) = 1.

3. Le problème RSA fort (SRSA) : il est considéré comme dicile de trouver un entier m et e > 1 tel que me≡ c mod n avec n un entier positif produit de deux premiers p et q.

4. Le problème du logarithme discret (DL) : il est considéré comme dicile de trouver un entier x avec 0 ≤ x ≤ p − 2 noté logαβ tel que αx ≡ β mod p avec p premier, α

un générateur de Z∗

p et β ∈ Z∗ p.

5. Le problème du logarithme discret généralisé(GDL) : il est considéré comme dicile de trouver un entier x avec 0 ≤ x ≤ n − 1 noté logαβ tel que αx = β avec G un groupe cyclique d'ordre n, α un générateur de G et β ∈ G.

6. Le problème de Die-Hellman (DH) : il est dicile de trouver αab mod p avec p premier, α un générateur de Z∗

7. Le problème de Die-Hellman généralisé (GDH) : il est dicile de trouver αab avec

G un groupe cyclique, α un générateur de G et les éléments αa et αb de ce groupe. Notons également le théorème suivant (Camenisch & Shoup, 2003) :

Dans le document Identités numériques : gestion inter-organisationnelle centrée sur l'utilisateur et respectueuse de la vie privée (Page 81-98)