Mise en Gage

equations de produits couplages mais nous n’en aurons pas besoin dans ce m´emoire.

Remarque 6. Il est important de noter que les preuves Groth-Sahai ne sont pas n´ecessairement des preuves de connaissance. En effet s’il est possible d’extraire simplement les ´el´ements X ∈ G1

et eX ∈ G2 des mises en gage, il n’en va pas de mˆeme des scalaires y_i ∈ Zp. Ce type de preuves n’est donc g´en´eralement pas utilis´e pour prouver la connaissance d’un logarithme discret.

3.4 Autres Primitives Cryptographiques

Outre les signatures num´eriques et les preuves de connaissance, que nous utiliserons tr`es fr´equemment dans ce m´emoire, nous ferons ´egalement appel `a deux autres primitives cryptogra-phiques, la fonction de hachage et la mise en gage.

3.4.1 Fonction de Hachage Cryptographique

Une fonction de hachage H est une fonction transformant n’importe quelle chaˆıne de bits en une autre de taille fixe, appel´ee empreinte. Elle est dite cryptographique si elle satisfait les deux conditions suivantes.

– R´esistance `a la pr´e-image : pour tout y appartenant `a l’image de H, il est difficile de trouver x ∈ {0, 1}^∗ tel que H(x) = y.

– R´esistance aux collisions : il est difficile de trouver x et x⁰ appartenant `a {0, 1}^∗ tels que H(x) = H(x0).

Une fonction v´erifiant la premi`ere de ces propri´et´es est ´egalement dite `a sens unique. Les fonctions de hachage cryptographiques font l’objet de standards tels que SHA-256 [SHA02] ou SHA-3 [SHA14] dont l’utilisation est aujourd’hui recommand´ee.

3.4.2 Mise en Gage

Un sch´ema de mise en gage cryptographique permet de masquer une donn´ee tout en gardant la possibilit´e de la r´ev´eler ult´erieurement. Il peut ˆetre compar´e `a une boˆıte verrouill´ee dans laquelle serait enferm´e un objet. Celui-ci resterait secret jusqu’`a ce que le d´etenteur de la cl´e choisisse de le r´ev´eler en ouvrant la boˆıte.

De mani`ere plus formelle, un sch´ema de mise en gage est d´efini par les 3 algorithmes suivants :

– l’algorithme Setup qui, prenant en entr´ee un param`etre de s´ecurit´e k, g´en`ere les param`etres publics p.p. du syst`eme ;

– l’algorithme Commit qui, prenant en entr´ee p.p. et un message m, retourne une mise en gage C ainsi qu’une valeur d’ouverture r ;

– l’algorithme Open qui, prenant en entr´ee C, r et m, retourne 1 si C est une mise en gage valide du message m pour l’ouverture r et 0 sinon.

Il est ´egalement possible de d´efinir un sch´ema de mise en gage extractible en imposant `a l’algorithme Setup de retourner, en plus de p.p., une cl´e d’extraction ek et en rajoutant la des-cription d’un algorithme Extract qui, prenant en entr´ee ek et une mise en gage C d’un message m, retourne m.

Chapitre 3 : Outils Cryptographiques

S´ecurit´e. Pour reproduire les fonctionnalit´es d’une boˆıte verrouill´ee, un sch´ema de mise en gage doit ˆetre contraignant et confidentiel. Ces deux propri´et´es sont d´efinies ci-dessous.

– Un sch´ema de mise en gage est calculatoirement contraignant si aucun adversaire probabi-liste polynomial n’est capable de produire une mise en gage C ainsi que 2 paires diff´erentes (r, m) et (r⁰, m⁰) telles que Open(C, r, m) = 1 = Open(C, r⁰, m⁰).

– Un sch´ema de mise en gage est calculatoirement confidentiel si aucun adversaire probabiliste polynomial n’est capable de distinguer, parmi deux messages de son choix, lequel est contenu dans une mise en gage C.

Exemple 3 : Pedersen [Ped92] a propos´e le sch´ema de mise en gage suivant, d´efini sur un groupe G d’ordre premier p.

– Setup(1^k) : soit k le param`etre de s´ecurit´e, cet algorithme retourne p.p. ← (g, h), o`u g et h sont deux g´en´erateurs de G.

– Commit(m) : pour mettre en gage un message m ∈ Zp, cet algorithme g´en`ere un scalaire r al´eatoire et retourne (C, r) ← (gr· hm, r).

– Open(C, r, m) : cet algorithme teste si C = g^r·hm, auquel cas il retourne 1. Sinon, il retourne 0.

Ce protocole peut ˆetre prouv´e calculatoirement contraignant sous l’hypoth`ese du logarithme discret. On peut ´egalement noter qu’il v´erifie une propri´et´e plus forte que la confidentialit´e cal-culatoire car le message m est parfaitement masqu´e (au sens de la th´eorie de l’information).

Deuxi`eme partie

M´ecanismes Cryptographiques pour

Chapitre 4

Techniques Cryptographiques pour le

Paiement Anonyme

Sommaire

4.1 Monnaie ´Electronique . . . . 33 4.2 Monnaie ´Electronique Divisible . . . . 35 4.2.1 D´efinition . . . 35 4.2.2 Mod`ele de S´ecurit´e . . . 36 4.2.3 Etat de l’Art . . . 39<sup>´</sup> 4.3 Une Nouvelle Construction . . . . 41 4.3.1 Id´ee G´en´erale . . . 41 4.3.2 Construction . . . 43 4.3.3 Preuves de S´ecurit´e . . . 47 4.4 Un Syst`eme D´eployable `a Grande ´Echelle . . . . 51 4.4.1 Id´ee G´en´erale . . . 51 4.4.2 Construction . . . 52 4.4.3 Preuves de S´ecurit´e . . . 56 4.5 Comparaison des Performances . . . . 60

Nous pr´esentons dans ce chapitre des outils cryptographiques pour le paiement anonyme. Nous commen¸cons par introduire le concept de monnaie ´electronique avant d’en pr´esenter une variante appel´ee monnaie ´electronique divisible. Nous d´ecrivons ensuite deux constructions respectant les contraintes d’efficacit´e d’un syst`eme de paiement et satisfaisant les exigences d’anonymat les plus strictes. Celles-ci sont issues des articles Divisible E-Cash Made Practical [CPST15a], publi´e `a la conf´erence PKC 2015, et Scalable Divisible E-Cash [CPST15b], publi´e `a la conf´erence ACNS 2015.

4.1 Monnaie ´Electronique

Les moyens de paiement ´electroniques offrent aujourd’hui un confort d’utilisation incompa-rable `a celui de la monnaie traditionnelle. En effet, leurs utilisateurs se retrouvent d´ebarrass´es des probl`emes d’appoint et de rendue de monnaie tout en b´en´eficiant d’une vitesse de transaction de l’ordre de la seconde. Malheureusement, chacun de leurs achats est aujourd’hui remont´e `a la banque, ce qui est bien loin d’ˆetre anodin. C’est mˆeme suffisant pour connaitre leurs goˆuts, leurs activit´es, leur croyances ou mˆeme leur ´etat de sant´e.

Pourtant, les moyens de paiement ´electroniques ne sont pas n´ecessairement incompatibles avec la protection de la vie priv´ee, comme le prouva Chaum lorsqu’il introduisit en 1982 le concept de monnaie ´electronique anonyme [Cha82].

Chapitre 4 : Techniques Cryptographiques pour le Paiement Anonyme

Une monnaie ´electronique vise `a reproduire, de mani`ere num´erique, le fonctionnement des esp`eces traditionnelles. En pratique, ces syst`emes consid`erent trois types d’entit´es : la banque, qui ´emet la monnaie, les utilisateurs, qui retirent des pi`eces aupr`es d’elle, et les marchands, chez qui les utilisateurs les d´epensent. Dans l’id´eal, l’ensemble des utilisateurs et celui des marchands devraient ˆetre confondus, c’est-`a-dire qu’une personne recevant une pi`ece (donc un marchand) devrait `a son tour pouvoir la d´epenser (devenant ainsi un utilisateur). Malheureusement, un tel syst`eme, qualifi´e de transf´erable, souffre d’une forte complexit´e qui lui est inh´erente [CP93]. Pour des raisons d’efficacit´e, on utilisera donc en pratique un syst`eme plus simple o`u les marchands doivent d´eposer `a la banque les pi`eces qu’ils ont re¸cues, ne pouvant donc pas les d´epenser `a nouveau.

La monnaie ´electronique pr´esente cependant une diff´erence fondamentale avec la monnaie traditionnelle : elle est ais´ement reproductible. Cette propri´et´e, propre `a toute donn´ee num´erique, pose un v´eritable probl`eme : comment la banque peut-elle empˆecher un utilisateur malhonnˆete de r´eutiliser plusieurs fois une mˆeme pi`ece ? Si le syst`eme n’´etait pas anonyme, il lui suffirait d’additionner l’ensemble des retraits d’un utilisateur ainsi que ses d´epenses et de s’assurer que la diff´erence reste positive. Malheureusement, cela est totalement impossible pour un syst`eme de monnaie ´electronique pour lequel on souhaite justement ´eviter cette tra¸cabilit´e. Toute la difficult´e de la conception de ce type de syst`eme est donc de fournir `a la banque un moyen de d´etecter les fraudes (appel´ees aussi double-d´epenses) sans remettre en cause l’anonymat.

Pour r´esoudre ce probl`eme, Chaum proposa le concept de signature aveugle. Cette primitive, formalis´ee dans [PS96], permet `a un utilisateur d’obtenir une signature σ sur un message m inconnu du signataire. Par ailleurs, ce dernier est incapable, lorsqu’il voit passer la paire (σ, m), de savoir `a quel moment il a ´emis cette signature. Dans le contexte de la monnaie ´electronique, une pi`ece va consister en une signature aveugle re¸cue de la banque par l’utilisateur. Ce dernier pourra ainsi la pr´esenter `a un marchand qui en v´erifiera la validit´e `a l’aide de la cl´e publique du syst`eme. Chaque fois qu’un marchand d´eposera une pi`ece `a la banque, celle-ci conservera dans un registre la signature σ associ´ee. Cela lui permettra de d´etecter les double-d´epenses (car une mˆeme signature apparaˆıtra alors pour plusieurs d´epˆots) mais pas d’identifier les utilisateurs car elle sera incapable, en raison des propri´et´es des signatures aveugles, de savoir `a qui elle a d´elivr´e la signature σ.

En th´eorie, le probl`eme du paiement ´electronique a donc ´et´e r´esolu par la construction de sch´emas de signatures aveugles efficaces (voir [PS96] pour quelques exemples). Malheureusement, l’usage de la monnaie ´electronique ainsi construite reste probl´ematique. En effet, comment ˆetre capable de g´erer n’importe quel montant ?

Une premi`ere solution, directement inspir´ee des esp`eces traditionnelles, serait de distribuer des pi`eces ´electroniques de montants diff´erents. En pratique, cela se traduirait par une banque qui utiliserait plusieurs paires {(sk1, pk<sub>1</sub>), . . . , (skr, pk<sub>r</sub>)} de cl´es de signatures aveugles, chacune ´etant associ´ee `a une certaine valeur. Cependant, supposons qu’un utilisateur dispose d’une pi`ece d’un montant de 10e et souhaite en d´epenser 8 e. Il devrait alors soit obtenir de la monnaie aupr`es de sa banque pour pouvoir faire l’appoint, soit se faire rendre la monnaie par le commer¸cant. La premi`ere possibilit´e n’est pas souhaitable en terme d’usage car elle n´ecessite d’ˆetre connect´e lors de la transaction. La deuxi`eme ne l’est pas non plus car l’utilisateur deviendrait alors un

marchand(car il recevrait une pi`ece) et perdrait du coup son anonymat (seuls les utilisateurs sont anonymes).

Une autre solution serait de n’utiliser que des pi`eces du plus petit montant possible, `a savoir 0.01e. Cependant, cela signifierait que l’utilisateur devrait stocker plusieurs milliers de signatures et, lors d’une d´epense, en envoyer plusieurs centaines au marchand qui devrait toutes les v´erifier. Dans leur article Compact E-Cash [CHL05], Camenisch, Hohenberger et Lysyanskaya ont partiel-lement r´esolu ce probl`eme en proposant le premier sch´ema capable de stocker tr`es efficacement plusieurs pi`eces `a la fois. Malheureusement, celles-ci doivent toujours ˆetre d´epens´ees une par une, ce qui reste inenvisageable en pratique.