Construction

elev´ee `a une puissance R connue. Le point important est que ce chiffr´e est g´en´er´e de mani`ere d´eterministe en fonction du sommet s. Tant que l’utilisateur sera honnˆete, lemasquehx

s ne sera utilis´e qu’une seule fois et assurera sa confidentialit´e. A l’inverse, un fraudeur n’aura pas d’autre choix que de r´eutiliser un masque, ce qui va permettre de l’identifier.

En effet, lorsqu’une double d´epense sera d´etect´ee, la banque disposera de deux traces de transactions contenant (t_s, v_s) et (t_s0, v_s0) o`u s et s<sup>0</sup> sont deux sommets partageant au moins une feuille commune f ∈ F<sub>n</sub>(s) ∩ F<sub>n</sub>(s<sup>0</sup>). Par cons´equent, nous avons e(h<sub>s</sub>,g<sub>es7→f</sub>) = e(h<sub>s</sub>0,<sub>e</sub>g<sub>s</sub>07→f) ainsi que l’´egalit´e suivante (o`u T = e(vs,_egs7→f) et T⁰ = e(vs0,_egs07→f)) :

T · T⁰⁻¹= e(upk^R,_egs7→f) · e(h^x_s,_egs7→f) · e(upk^−R0,_egs07→f) · e(h^x_s0,_egs07→f)⁻¹ = e(upk,_eg^R_s7→f·_eg_s^−R07→f⁰ ).

L’´el´ement T · T⁰⁻¹ ne d´epend donc que de upk et de param`etres connus des transactions. Il est alors possible de tester, pour toute cl´e publique upk<sub>i</sub> du syst`eme, si T · T⁰⁻¹= e(upk_i,_eg_s7→f^R ·_eg^−R_s07→f⁰ ) jusqu’`a tomber sur une ´egalit´e.

L’algorithme d’identification (Identify) a donc un coˆut lin´eaire en le nombre d’utilisateurs, ce qui n’est pas vraiment probl´ematique car les cas de fraudes restent rares notamment en raison de l’utilisation de p´eriph´eriques s´ecuris´es (tels que des cartes `a puces). Par ailleurs, cette proc´edure peut ˆetre efficacement parall´elis´ee et d´el´egu´ee comme c’est le cas pour le sch´ema de tra¸cage de traˆıtres d´ecrit dans [CPP05].

4.3.2 Construction

Nous d´ecrivons `a pr´esent, de mani`ere plus formelle, les algorithmes constituant notre syst`eme de monnaie ´electronique divisible anonyme en distinguant le cas d’une construction dans le ROM de celui d’une construction dans le mod`ele standard. Cette distinction est rendue n´ecessaire par le fait que les preuves Groth-Sahai ne permettent pas de prouver efficacement la connaissance de scalaires, contrairement aux preuves de connaissance de type Schnorr. Dans le premier cas

Chapitre 4 : Techniques Cryptographiques pour le Paiement Anonyme

l’utilisateur devra donc prouver la connaissance d’un ´el´ement u^x₂ ∈ G1(pour un certain param`etre public u2), tandis que dans le deuxi`eme cas, prouver la connaissance de x suffira.

– Setup(1^k, V ) : soient (G1, G2, GT, e) la description de groupes bilin´eaires d’ordre p et g, h, u1, u2, w (resp._eg) des g´en´erateurs de G1 (resp. G2). L’entit´e g´en´erant les param`etres du syst`eme (voir remarque 9) s´electionne une fonction de hachage H : {0, 1}^∗→ Zp r´esistante aux collisions et construit les ´el´ements suivants :

– pour tout s ∈ Sn, rs $ ← Zp et (gs, hs) ← (g^rs, h^rs) ; – pour tout f ∈ Fn, lf $ ← Zp;

– pour tout s ∈ S_n, pour tout f ∈ F_n(s), _eg_s7→f ←_eg^lf/rs.

Les param`etres publics du syst`eme sont alors d´efinis comme ´etant (G1, G2, GT, e), ainsi que g, h, u1, u2, w, _eg, et G = e(g,_eg), la fonction H, et les ensembles {(gs, hs), s ∈ Sn} et {_eg_s7→f, s ∈ Sn, f ∈ Fn(s)}. Par ailleurs, en fonction du mod`ele de s´ecurit´e, on rajoute : – une autre fonction de hachage H : {0, 1}^∗ → Zp, qui sera mod´elis´ee par un oracle

al´eatoire ;

– ou une chaˆıne de r´ef´erence commune (CRS) pour le syst`eme de preuves Groth-Sahai ainsi que la description d’un sch´ema de signature `a usage unique Σ_ots tel que celui propos´e dans [BB08].

Il est important de noter que les utilisateurs et les marchands ont seulement besoin de connaˆıtre les diff´erents g´en´erateurs et {(g_s, h_s), s ∈ S_n} (ainsi que H, ou CRS et Σ_ots). En pratique, l’ensemble {_egs7→f, (s, f ) ∈ Sn× F_n} sera seulement utilis´e par la banque, tandis que {l_f, f ∈ Fn} ne sera plus d’aucune utilit´e dans le syst`eme.

– BKeygen() : apr`es avoir re¸cu les param`etres du syst`eme, la banque va s´electionner deux sch´emas de signature.

– Σ0 = (Keygen, Sign, Verify), dont l’espace des message est G²1, pour signer certains ´

el´ements des param`etres publics. Un choix possible est le sch´ema de signature propos´e dans [AGHO11] bien qu’il v´erifie une propri´et´e de s´ecurit´e (EUF-CMA) nettement plus forte que ce dont nous avons besoin. En pratique, un sch´ema sˆur face `a des attaques s´electives `a messages choisis serait suffisant.

– Σ1 = (Keygen, Sign, Verify), dont l’espace des messages d´epend du mod`ele de s´ecurit´e. – ROM : l’espace des messages est ici Z<sup>2</sup>p. Il est cependant n´ecessaire que le sch´ema choisi soit compatible avec un protocole Σ<sub>1</sub>.SignCommit qui, ´etant donn´e (u<sup>x</sup><sub>1</sub>, u<sup>y</sup><sub>2</sub>) pour une certaine paire (x, y) ∈ Z<sup>2</sup>p (donc une mise en gage de (x, y)), retourne une signature valide σ sur (x, y). C’est par exemple le cas des sch´emas dˆus `a Camenisch et Lysyans-kaya et `a Boneh et Boyen que nous avons pr´esent´es dans la section 3.2.2 ou celui que nous d´ecrivons dans le chapitre 8.

– Mod`ele Standard : l’espace des messages est ici G²1, ce qui rend de nouveau possible l’utilisation du sch´ema de [AGHO11].

Dans tous les cas, la banque obtient (sk₁, pk₁) ← Σ₁.Keygen(p.p.) ainsi que (sk⁽ⁱ⁾₀ , pk⁽ⁱ⁾₀ ) ← Σ0.Keygen(p.p.) pour chaque niveau i de l’arbre (0 ≤ i ≤ n) et calcule, pour tout s ∈ Sn, la signature τs ← Σ₀.Sign(sk^(|s|)₀ , (gs, hs)). Finalement, il d´efinit bsk comme ´etant sk1 et bpk comme ´etant ({pk⁽ⁱ⁾₀ }_i, pk₁, {τs}_s∈Sn).

– Keygen() : chaque utilisateur (resp. marchand) choisit une cl´e secr`ete al´eatoire usk ← Z^$ p

(resp. msk) et calcule upk ← g^usk (resp. mpk ← g^msk). Dans ce qui suit, nous supposerons que upk (resp. mpk) est publiquement accessible, c’est-`a-dire que tout le monde peut en obtenir une copie valide.

– Withdraw(B(bsk, upk), U (usk, bpk)) : pour retirer une pi`ece divisible, l’utilisateur commence par g´en´erer un scalaire x ∈ Zp al´eatoire, puis calcule u<sup>usk</sup><sub>1</sub> et u<sup>x</sup><sub>2</sub>. Il envoie alors upk, u<sup>usk</sup><sub>1</sub> et u<sup>x</sup><sub>2</sub> `a la banque et lui prouve, en utilisant par exemple une extension du protocole interactif de Schnorr, sa connaissance de x et usk. Si cette preuve est valide et que u^x₂ n’a pas d´ej`a

4.3. Une Nouvelle Construction

´et´e utilis´e, la banque

– ROM : ex´ecute le protocole Σ1.SignCommit sur (u^usk₁ , u^x₂) et envoie la signature r´esultante σ `a l’utilisateur qui d´efinit C ← (x, σ).

– Mod`ele Standard : ex´ecute l’algorithme σ ← Σ<sub>1</sub>.Sign(sk<sub>1</sub>, (u<sup>usk</sup><sub>1</sub> , u<sup>x</sup><sub>2</sub>)) et retourne σ `a l’utilisateur qui d´efinit C ← (x, σ).

– Spend(U (usk, C, bpk, mpk, 2`), M(msk, bpk, 2`)) : pour d´epenser une valeur 2`, l’utilisateur s´electionne un sommet non d´epens´e s de niveau n − ` et calcule R ← H(inf o) (o`u inf o est un ensemble de donn´ees publiques associ´ees au paiement, telles que le montant, la date, etc...) ainsi que (t_s, v_s) ← (gx

s, upk^R· hx

s). Il doit alors prouver que t_s et v_s sont bien form´es, c’est-`a-dire qu’il a utilis´e des valeurs pr´ealablement certifi´ees lors d’un retrait, donc une preuve de connaissance de σ, et qu’il a utilis´e une paire valide (g<sub>s</sub>, h<sub>s</sub>), donc une preuve de l’existence de τ<sub>s</sub>. L`a encore, le protocole dans le ROM diff`ere de celui dans le mod`ele standard.

– ROM : l’utilisateur fournit une preuve de connaissance de usk, x, g_s, h_s, τ_s, et σ v´erifiant : ts= g_s^x∧ v_s= (g^R)^usk· h^x_s ∧ Σ1.Verify(pk₁, (usk, x), σ) = 1

∧ Σ₀.Verify(pk^(n−`)₀ , (g_s, h_s), τ_s) = 1.

Cette preuve est alors convertie en une signature de connaissance Π sur le message R, en utilisant la m´ethode Fiat-Shamir pr´esent´ee dans la section 3.3.3.

– Mod`ele Standard : l’utilisateur doit fournir une preuve Groth-Sahai de connaissance de σ et τs. Cependant, l’utilisation de ce type de preuves pose un probl`eme car elles peuvent ˆ

etre r´eg´en´er´ees, c’est-`a-dire qu’´etant donn´ee une preuve valide π, il est possible, sans la connaissance des secrets, d’en calculer une nouvelle version ˜π 6= π prouvant les mˆemes affirmations. Dans notre cas, un marchand malhonnˆete pourrait r´eg´en´erer la preuve d’une trace valide et la d´eposer `a nouveau. Un utilisateur serait alors injustement accus´e de fraude, ce qui contredirait la propri´et´e de non-diffamation attendue d’un syst`eme de monnaie ´electronique divisible.

Pour ´eviter cela, l’utilisateur va g´en´erer une paire de cl´es pour un sch´ema de signature `

a usage unique (sk_ots, pk_ots) ← Σ_ots.Keygen(1k) et certifier la cl´e publique en calculant µ ← w

1

usk+H(pkots). La cl´e secr`ete sera ensuite utilis´ee pour signer l’int´egralit´e de la trace (et donc les preuves). Une r´eg´en´eration des preuves donne lieu `a une nouvelle trace qui n´ecessite donc une nouvelle signature. Par cons´equent, l’attaque pr´ec´edente ne s’applique plus car aucune entit´e, `a part l’utilisateur, n’est capable de la produire.

Le calcul de la preuve Groth-Sahai commence par les mises en gages de usk, x, gs, hs, τ_s, σ, µ, U₁ = u^usk₁ et U₂ = u^x₂. L’utilisateur fournit ensuite une preuve non-interactive `a divulgation nulle π que celles-ci v´erifient :

t_s= g^x_s ∧ v_s = (g^R)^usk· h^x_s ∧ U₂ = u^x₂∧ U₁= u^usk₁ ∧ µ^(usk+H(pkots))= w

ainsi qu’une preuve non-interactive π⁰ satisfaisant l’indistinguabilit´e des t´emoins que les valeurs mises en gage v´erifient :

1 = Σ0.Verify(pk^(n−`)₀ , (gs, hs), τs) ∧ 1 = Σ1.Verify(pk₁, (U1, U2), σ)

Finalement, l’utilisateur calcule η ← Σ_ots.Sign(sk_ots, H(t_s||v_s||π||π0||R)) et l’envoie `a M ainsi que t_s, v_s, pk_ots, π, π⁰.

Dans tous les cas, le marchand v´erifie que les preuves et les signatures sont valides auquel cas il accepte la transaction. Il conserve alors Z ← (t_s, v_s) et soit la signature de connaissance Π (dans le cas du ROM) soit l’ensemble Π ← (π, π⁰, pk_ots, η) (dans le cas du mod`ele standard).

Chapitre 4 : Techniques Cryptographiques pour le Paiement Anonyme

– Deposit(M(msk, bpk, (2^{`</sup>, Z, Π)), B(bsk, L, mpk)) : lorsqu’un marchand fait remonter la trace d’un paiement `a la banque, celle-ci va commencer par v´erifier qu’elle n’a pas d´ej`a ´et´e re-mont´ee et qu’elle est valide. Si c’est le cas, elle va, pour chaque s<sup>0</sup> de niveau n − ` et f ∈ F_n(s⁰), calculer z_i ← e(t_s,_eg_s07→f). Elle v´erifie ensuite que ∀i, z_i ∈ L auquel cas elle/ ajoute ces ´el´ements `a cette liste (voir la remarque ci-dessous) et conserve la trace (2<sup>`}, Z, Π). Sinon, il existe un ´el´ement z⁰ ∈ L tel que z_i = z⁰. La banque retrouve alors la trace (2^{`0</sup>, Z<sup>0</sup>, Π<sup>0</sup>) correspondante et retourne [(2<sup>`}, Z, Π), (2^`0, Z⁰, Π⁰)].

– Identify((2^{`</sup>1, Z1, Π1), (2<sup>`}2, Z2, Π2), bpk) : pour identifier l’auteur d’une double d´epense, l’entit´e ex´ecutant cet algorithme va commencer par v´erifier la validit´e des deux traces et retourne ⊥ si l’une d’entre elles n’est pas correcte. Il calcule alors, pour i ∈ {1, 2} et pour toute feuille f , les listes S_i,f ← {e(t_si,_eg_s7→f), ∀s ∈ Sn tel que |s| = |si| et f ∈ F_n(s)}, et retourne ⊥ s’il n’y a aucune collision entre S_1,f et S_2,f pour toute feuille f . Sinon, on peut supposer (voir la remarque ci-dessous) que nous avons e(ts1,g_es17→f) = e(ts2,_egs27→f) avec ts1 = g^x_s1 et ts2 = g^x_s2 pour des sommets s1, s2 ∈ S_n. Comme expliqu´e dans la section pr´ec´edente, on a alors la relation e(v_s1,_eg_s17→f) · e(v_s2,_eg_s27→f)⁻¹ = e(upk,g_es7→f^R ·_eg^−R_s07→f⁰ ). Il ne reste donc plus qu’`a calculer e(upk_i,g_eR

s7→f ·_eg^−R_s07→f⁰ ) pour toutes les cl´es publiques jusqu’`a avoir une correspondance, auquel cas on retourne upk<sub>i</sub>. On peut remarquer que la propri´et´e de r´esistance aux collisions attendue de H est n´ecessaire. Sans celle-ci, on pourrait avoir R = R<sup>0</sup>, et donc <sub>e</sub>g<sub>s7→f</sub><sup>R</sup> ·<sub>e</sub>g<sup>−R</sup><sub>s</sub>07→f<sup>0</sup> = 1<sub>G2</sub> dans le cas o`u s = s⁰, rendant impossible toute identification.

Remarque 9.

1. Nous avons consid´er´e, pour plus de simplicit´e, que l’algorithme Setup ´etait ex´ecut´e par une unique entit´e. Cependant, la connaissance des scalaires (rs, l_f) utilis´es dans cette phase permet de casser l’anonymat du sch´ema. La g´en´eration de la CRS des preuves Groth-Sahai pose le mˆeme probl`eme. En pratique, il est donc indispensable que les param`etres du syst`eme soient g´en´er´es par une autorit´e de confiance ou alors coop´erativement par diff´erentes entit´es aux int´erˆets divergents (telles que la banque et un ensemble d’utilisateurs). Par exemple, la banque pourrait g´en´erer as, cf

$

← Zp pour tout s ∈ Sn et f ∈ Fn, calculer As ← gas

et eA_s7→f ←_eg^cf/as, et prouver sa connaissance de a_s et c_f. Les utilisateurs pourraient alors choisir des scalaires al´eatoires bs et d_f, calculer Bs ← Abs

s ainsi que eB_s7→f ← eA^df/bs

s et prouver connaissance de b_s et d_f.

Si toutes les preuves sont valides alors les param`etres publics sont d´efinis par g_s ← B_s et e

g_s7→f ← eB_s7→f dont les logarithmes discrets ne sont connus par aucune entit´e.

2. Le sommet impliqu´e dans une d´epense n’´etant pas connu, la banque doit calculer et stocker 2ⁿ´el´ements z_i `a chaque fois qu’une transaction lui est remont´ee, peu importe son montant. Dans le pire des cas (si l’utilisateur d´epense sa pi`ece centime par centime) la banque se retrouvera oblig´ee de conserver 2²ⁿ´el´ements pour chaque pi`ece d’une valeur 2<sup>n</sup>. Cependant, en pratique, la banque n’a pas besoin de stocker les ´el´ements z<sub>i</sub> ∈ GT mais seulement leur empreinte (nettement plus petite) H<sup>0</sup>(z<sub>i</sub>) pour une certaine fonction de hachage H<sup>0</sup>. En cas de collision, la banque commencera par recalculer les zi pour ˆetre sˆure que celle-ci n’est pas due `a la fonction H⁰ avant de lancer la proc´edure d’identification.

3. Le risque de cette construction, o`u la liste L contient un grand nombre de num´eros de s´erie invalides, serait la pr´esence de faux positifs, `a savoir deux pi`eces de secrets respectifs x1

et x2 pour lesquelles il existerait des sommets s1, s⁰₁, s2 et s⁰₂ tels que e(g^rs1^x1,_eg^yf/rs0 1) = e(g^rs2^x2,_eg^yf/rs0

2) pour un certain f ∈ Fn. Cependant, cela impliquerait que x1rs1r_s0 2 = x2rs2r_s0

1 ce qui n’arrive qu’avec une probabilit´e n´egligeable lorsque x1 et x2sont s´electionn´es al´eatoirement.

4.3. Une Nouvelle Construction

La s´ecurit´e de notre construction repose sur celle des sch´emas de signatures employ´es mais ´

egalement sur l’hypoth`ese EXDH − 2. Les r´esultats la concernant sont formellement ´enonc´es par le th´eor`eme suivant. Bien que les deux variantes (ROM et mod`ele standard) soient tr`es similaires, l’analyse de leur s´ecurit´e diff`ere sur l’une des propri´et´es et n´ecessite donc d’ˆetre ´etudi´ee s´epar´ement.

Th´eor`eme 30. 1. Dans le mod`ele de l’oracle al´eatoire, et en supposant que la fonction H est r´esistante aux collisions, notre syst`eme de monnaie ´electronique divisible est anonyme sous l’hypoth`ese EXDH − 2, tra¸cable si Σ0 est EUF-SCMA sˆur et Σ1 est EUF-CMA sˆur, et satisfait la propri´et´e de non-diffamation sous l’hypoth`ese DL.

2. Dans le mod`ele standard, et en supposant que la fonction H est r´esistante aux collisions, notre syst`eme de monnaie ´electronique divisible est anonyme sous l’hypoth`ese EXDH − 2, tra¸cable si Σ0 est EUF-SCMA sˆur et Σ1 est EUF-CMA sˆur, et satisfait la propri´et´e de non-diffamation sous l’hypoth`ese q − SDH si Σ_ots est un sch´ema de signature `a usage unique dont la s´ecurit´e est forte.