Algorithme de génération distribuée de modules RSA

In document Le partage de clés cryptographiques : Théorie et Pratique (Page 90-94)

Partie III Applications 157

Chapitre 10 Chiffrement du même message sous plusieurs clés 203

3.2 Algorithme de génération distribuée de modules RSA

distribution uniforme42sur un même intervalle. Ceci n’est pas un problème car une somme de variables aléatoires tend vers une gaussienne selon le Théorème de la Limite Centrale. On peut montrer que cette gaussienne est très étalée. On peut estimer la moyenne de la variable aléatoire sommeSià 2

L(N)−3

2 /n+1

2

et de variance 2

L(N)−3 2 /n2−1

12 . Ceci permet de caractériser complètement la variance. Il est facile de voir que cette variance est suffisamment grande et qu’elle contient plus de2128nombres premiers car elle est supérieure à>2128×log(2128).

Une deuxième conséquence de ce protocole est que chaque serveur peut obtenir l’information sui-vante :pi< p. Boneh et Franklin ont montré que cette information n’est pas utile à un adversaire.

Dans le lemme 2.1. de [27], Boneh et Franklin réduisent le protocole distribué au protocole centralisé et montrent en particulier que s’il existe un attaquant A qui réussit à casser la sécurité du protocole distribué de génération de clé (i.e., avectparts de la clé secrète), il existe un simulateurS qui factorise une fraction non-négligeable des modules RSAN de tailleL(N).

Théorème 9. Supposons qu’il existe un algorithme en temps polynomial A qui étant donné : (1) un aléaN ∈Z(2)L(N)choisi dans la distribution deZ(2)L(N)induite par le protocole, et (2) les partshpi, qiidetparties, factoriseN avec probabilité au moins1/L(N)δpour un certainδ. Alors il existe un algorithmeB fonctionnant en temps polynomial en moyenne qui factorise1/(4(t+ 1)3L(N)δ)des entiers dansZ(2)L(N).

3.4 Schéma complètement distribué de signature RSA à seuil

Nous présentons ici la solution que nous avons conçue pour distribuer la preuve de validitié et l’en-semble du schéma de signature RSA à seuil de Shoup. Nous commencerons par présenter le problème, c’est-à-dire à identifier les cas où les modules RSA sûrs sont nécessaires dans le schéma de Shoup, puis nous définirons le modèle de sécurité. Ensuite, nous décrirons comment modifier l’algorithme de

42. Dans le chapitre 6, nous montrerons qu’un adversaire peut biaiser cette distribution de façon à obtenir de l’information sur la clé secrète. Ceci est une attaque sur le protocole distribué de génération de la clé.

Boneh et Franklin afin qu’il génère des modules RSA ayant des propriétés spéciales. Nous montrerons que le schéma de Shoup est toujours résistant aux attaques passives avec les modules ainsi générés et nous montrerons que ce schéma est aussi robuste, c’est-à-dire sûr contre les attaques actives. Enfin, nous donnerons les paramètres pratiques pour notre schéma.

SoitN =pqtel quep= 2p0+ 1etq = 2q0+ 1où en généralp0 =Q

ipieietq0 =Q

jqjej. Posons M =p0q0. On rappelle qu’un nombre premierpest dit nombre premier sûr sipetp0sont simultanément premiers. Un module RSAN =pqcomposé de deux nombres premiers sûrs est appelé un module RSA sûr.

3.4.1 Problématique

Comme on va le voir dans la suite, les nombres premiers sûrs sont utilisés dans la génération de la clé (afin de prouver que le schéma de partage de secret de Shamir [170] est sûr dans l’anneauZM43), et dans la preuve de validité. Expliquons ici le second problème qui est moins évident.

Où est le problème ?

La propriété de robustesse garantit que même sit joueurs malicieux envoient de fausses parts de signature, le schéma générera quand même une signature correctes. Cette propriété est nécessaire car sinon le combineur doit résoudre le problème de la sélection des parts correctes44.

Par exemple, le combineur reçoit les parts de signature des serveurs et doit générer la signature. Un moyen pour lui consiste à choisir au hasardt+ 1parts de signature, à générer une signature possible s0 et à tester si s0 est une signature valide de m. Si le résultat est correct, la signature a été trouvée, sinon, le combineur doit tester un autre groupe det+ 1parts de signature. Comme le combineur ne peut pas deviner où sont les mauvaises parts, il doit faire face à une explosion combinatoire exponentielle d’essaisCnt+1. Par conséquent, il est nécessaire de construire un test efficace afin de vérifier si un serveur a correctement répondu à une question. Comme on l’a vu dans la sous-section 3.2.4, Shoup a proposé une preuve efficace non-interactive.

Nos résultats

Nous allons montrer que le protocole de Shoup peut être modifié pour fonctionner sous des hypo-thèses standards avec des modules RSA ayant des propriétés spéciales et que ces modules peuvent être générés de manière distribuée.

Les modules sûrs sont nécessaires dans la preuve de validité et dans le protocole de génération des clés. De plus, différentes caractéristiques de ces nombres sont utilisées dans la preuve de validité. En effet, le protocole de Shoup utilise deux propriétés importantes du sous-groupe des carrés QN de ZN quand unNest module sûr. D’une part, ce sous-groupe est cyclique et d’autre part, son ordreM n’a pas de petits facteurs premiers ce qui permet de simuler le partage à la Shamir. Le groupe cyclique est utilisé pour montrer l’existence du logarithme discret dans la preuve de robustesse. L’utilisation des nombres premiers sûrs permet de garantir qu’avec probabilité écrasante, un élément pris au hasard dansQN est un générateur.

Notre première observation concerne le lien entre la structure deQN liée aupgcd(p−1, q−1)et la recherche de générateurs dans QN liée à la décomposition en facteurs premiers de p−12 et de q−12 .

43. L’article d’origine de Shamir prouvait la sécurité dans un corps finiZp.

44. On précise que l’algorithme de Berlekamp-Welch (cf. chapitre 2) ne peut pas être utilisé ici car on aurait besoin de résoudre un système d’équations linéaires dans les exposants et que par exemple dansZp, cela reviendrait à résoudre le problème de Diffie-Hellman ou du logarithme discret.

En particulier, si p−12 et q−12 n’ont pas de petits facteurs premiers, alors avec forte probabilité un petit nombre d’éléments pris au hasard génère le groupeQN en entier. Si nous choisissons plusieurs éléments au hasard(g1, . . . , gk), on peut garantir que le groupe généré parhg1, . . . , gkiestQNen entier avec forte probabilité. De telles techniques ont déjà été utilisées par Frankel et al. dans [80] et un traitement plus précis a été effectué par Poupard et Stern dans [157]. De plus, en utilisant une astuce de Gennaro et al.

qui est apparue en premier dans [91] et le protocole récemment proposé par Catalano et al. dans [40], le calcul de pgcd(p−1, q−1)peut être effectué de manière distribuée. Ces méthodes permettent de conserver un algorithme de génération de clé efficace.

Dans cette section, nous montrons comment construire de manière conjointe des modules RSA de telle façon que le sous-groupeQN soit cyclique, ce qui garantit l’existence des logarithmes discrets45 et des générateurs deQN. De plus, l’ordreM de ce groupe ne contient pas de petits facteurs premiers plus petits qu’une borne de crible B. Cette vérification n’augmente pas trop le temps d’exécution de l’algorithme de génération de clé.

3.4.2 Modèle de sécurité

en temps polynomial. Considérons le scénario suivant :

– Durant la phase d’initialisation, les serveurs utilisent l’algorithme de génération distribuée pour créer les clés publique, privées et de vérification. La clé publique (N, e) et toutes les clés de vérificationvku,vku,isont publiées et chaque serveur obtient sa partdide la clé secrèted.

– Pour signer un message m, le combineur commence par envoyer m aux serveurs. En utilisant leur clé secrète di et ses clés de vérification vku,vku,i pour u ∈ [1, k], chaque serveur exécute l’algorithme de part de signature et retourne une part de signature σi en même temps qu’une preuve de validité de la part de signaturepreuvei. Finalement, le combineur utilise l’algorithme de combinaison pour générer la signature, si suffisamment de parts de signature sont valides et disponibles.

Les adversaires

Nous considérons un adversaire capable de corrompre jusqu’àtparmi lesnserveurs. Une telle cor-ruption peut être passive, i.e. l’attaquant peut seulement intercepter les messages des serveurs et lire la mémoire d’au plust serveurs. Il peut aussi tenter de faire échouer les serveurs ou de les arrêter. Fina-lement, il peut être actif; dans ce cas, l’adversaire contrôle complètement le comportement des serveurs corrompus. Dans la suite, nous considérons uniquement des adversaires non-adaptatifs qui choisissent les serveurs qu’ils souhaitent corrompre avant la phase de génération des clés.

Propriétés des schémas de signature à seuil

Les deux propriétés des schémas de signature à seuiltparminavect < n/2qui nous intéressent sont la robustesse et la non-forgeabilité.La robustessegarantit que même sitserveurs corrompus envoient des mauvaises parts de signature, le schéma retournera toujours une signature correcte.

Lanon-forgeabilitégarantit que tout sous-ensemble det+ 1joueurs peut générer une signatures, mais interdit la génération par tout ensemble de moins detjoueurs.

Les jeux de l’adversaire

Dans cette sous-section, nous décrivons les notions de sécurité pour l’algorithme de génération de clés à seuil et le protocole de signature à seuil sous forme de jeux que tente de gagner l’adversaire. Nous devons montrer que les informations révélées pendant ces protocoles n’aident pas l’adversaire.

Le jeu pour la version distribuée de la génération de clé. La validité de la génération de clé exige que les distributions de probabilité des clés secrètesd,p,q, et de la clé publique(N, e)paraissent uniformes à l’adversaire.

La sécurité de la génération des clés exige que s’il existe un adversaireAqui corrompt au plustserveurs au début du jeu, alors il ne peut pas obtenir plus d’information sur les clés secrètes détenues par les joueurs non corrompus.

Le jeu pour le protocole de signature à seuil. La sécurité du protocole de signature signifie que s’il existe un adversaire A qui corrompt au plust serveurs au début du protocole et qui peut obtenir des signatures de messages de son choix, alors il ne peut pas forger une signature sur un nouveau message.

Remarques. On peut remarquer que nous ne montrons pas que l’information apprise durant le protocole de génération de clé n’aide pas l’adversaire à déchiffrer ou à signer le message. Nous faisons ici une hypothèse plus forte sur un adversaire qui peut factoriser le moduleN comme le font Boneh et Franklin dans [27].

Le but de cette section est de générer des modules RSA tels que le groupe des carrés est un groupe cyclique dont l’ordre ne contient pas de petits facteurs premiers et des clés pour le schéma de signature de Shoup.

Pour ce faire, nous revisitons l’algorithme de génération partagée de clés RSA de Boneh-Franklin pour produire des modules RSA tels queN =pq,pgcd(p−12 ,q−12 ) = 1et ni p−12 ni q−12 n’ont de petits facteurs premiers. Nous utilisons un algorithme de crible pour améliorer simultanément le protocole de génération de clé, la probabilité de trouver un ensemble de générateurs de QN, et pour rendre sûr le schéma de partage de secret de Shamir. Nous prouvons enfin la robustesse et la sécurité de ce nouveau protocole distribué de génération de clés.

Génération distribuée de modules RSA de forme spéciale

Nous décrivons dans la figure 3.3 une adaptation du protocole de Boneh et Franklin pour générer un module RSA partagé, puis nous montrons comment générer les clés de vérification dont nous avons besoin.

1. Dans la première étape, chaque serveur choisit au hasard deux valeurspi etqi dans l’intervalleh√

2.2L(N)/2−1,b2L(N)/2n −1ch

selon [176], oùL(N)est la taille en bits du moduleN.

2. Les serveurs effectuent un crible sur les entiers partagés(p1+. . .+pn)−1et(q1+ . . .+qn)−1. Puis, ils vérifient sipgcd(4P, p−1)= 2? et sipgcd(4P, q−1)= 2? où P =Q

2<pi<BpietBla borne du crible en utilisant l’algorithme GCD.

3. Puis le protocole BGW, décrit dans le chapitre 9 est exécuté pour calculer le produit N dep1+. . .+pnetq1+. . .+qnet pour calculer le produitϕ(N)de(p1+. . .+pn)−1 et de (q1 +. . .+qn)−1. Les serveurs vérifient ensuite de manière distribuée si pgcd(ϕ(N), N −1)= 1? en utilisant l’algorithme GCD.

4. Ensuite, les parties exécutent un test de biprimalité similaire au test de Fermat modulo N. Nous fixonsp=p1+. . .+pnetq =q1+. . .+qn.

In document Le partage de clés cryptographiques : Théorie et Pratique (Page 90-94)