Jointly Generating Random Keys for the Fully Distributed Environment

Präsentation zum Thema: "Jointly Generating Random Keys for the Fully Distributed Environment"—  Präsentation transkript:

1 Jointly Generating Random Keys for the Fully Distributed Environment
Kryptowochenende, 2. Juli 2006 Jointly Generating Random Keys for the Fully Distributed Environment Sebastian Faust K.U. Leuven 1/29

2 4. Zusammenfassung und weiterführende Ansätze
Überblick 1. Motivation 2. Grundlagen 3. Das k-JGRK Protokoll 4. Zusammenfassung und weiterführende Ansätze First of all, let me provide you with a short outline of my talk of today. I will start with a short motivation of my presentation and show you some examples why there should be a special consideration for protocols in a fully distributed environment and for the feature of robustness. [ENTER] Following that, I will mention some of the basics and notations, which are needed in the rest of my talk. [ENTER] Afterwards we will take a look at the technique of distributed key generation. Here, I will give you a short introduction to the technique of Distributed Key Generation and will show you, what the main drawbacks of using the well known DKG protocols are. [ENTER] In section 4, we will then take a closer look at how these drawbacks can be solved. I will introduce to you two new protocols, the k-DKG protocol and the P2P-DKG which can be used to solve special tasks related to the distributed key generation. [ENTER] Finally, we will conclude and take a look at some approaches for further research. 2/29

3 1. Motivation – Verteilte Netzwerke
Wieso ist Schlüsselerzeugung in verteilten Netzwerken notwendig? Hmm...Kann man Charlie Brown vertrauen? Er ist so leichtgläubig. Kein Problem! Da kann ich helfen... 4 7 8 9 Charlie Brown ist ja eigentlich ganz süß, aber was ist mit Lucy??? Patty war fies zu mir. Sie hat mein Schnuffeltuch gewaschen? 4789 4789 Maybe you ask yourself why there is a need for a special consideration of key generation protocols in the fully distributed environment. [ENTER] Let me motivate the answer to this question with a short story out of Snoopies life. Coming Friday, the Peanuts want to throw a big birthday party for Woodstock and have therefore collected money to buy the famous chocolate chip cookies. Luckily, there is currently a special offer in the super market, so they decide to buy the cookies right now and save them till Friday evening. But now the Peanuts have the problem where to put the cookies so that nobody can easily eat the cookies alone. Although they know each other for a long time, they think if they can trust each other…[ENTER] While the friends are thinking, [ENTER] Snoopy proposes the following solution to the problem: He encloses the biscuit in his safe, for whose a 4-digit number is needed to open it. All of them, Lucy, Linus, Charlie and Patty gets one digit of the number, so that the safe can only be opened jointly. The friends are enthusiastic with this idea and so Snoopy distributes the digits. [ENTER] But now look what could happen if Snoopy isn’t trustworthy [ENTER] 3/29

4 1. Motivation – Verteilte Netzwerke
Aber was passiert, wenn Snoopy nicht vertrauenswürdig ist? 4789 4 7 8 1 4789 As you can see Snoopy is corrupted and distributes a false key. Charlie Brown gets instead of the correct number 9 the false value 1. With this numbers in hand there is no possibility to open the safe. [ENTER] So the moral of this short story is: Trusted Third parties are very rare! 4/29

5 7 4 4789 2 9 8 Wieso ist Überprüfbarkeit wichtig?
1. Motivation – Überprüfbarkeit Wieso ist Überprüfbarkeit wichtig? 7 4 4789 To show why the robustness is an essential feature of a protocol especially in the case of fully distributed environments, consider the following scenario… [ENTER] The Peanuts met before the party and jointly want to open the safe… But there is a problem… as you can see in the cartoon, Charlie Brown is corrupted by an adversary and hence uses instead of the correct number 9 a false number 2. So if now each party enters its digit, the door of the safe stays closed. But as long as Snoopy stays silent, there is no way to find out who the saboteur is. Finally, for a non-involved observer, each party is guilty for this situation with probability of 25%. Therefore, developing robust protocols is an important task and needs special consideration in the fully distributed environment. After this short motivation, let me now move on to some of the basics and notations, I will be using in the rest of this talk. [ENTER] 2 9 8 5/29

6 Existenz von zuverlässigen Broadcastkanalen
2. Grundlagen – Das Netzwerk… Existenz von zuverlässigen Broadcastkanalen As you can see here in the graphic, a reliable broadcast channel allows a party to deliver an identical message simultaneously to the other parties in the network. [ENTER] One can easily ask why not use point-to-point connections between the one sender and the receivers to simulate the broadcast-channel? The problem here would be, that by using this approach the sender might easily send different messages to each other. Therefore in practice the implementation of a reliable broadcast channel is more complex and usually leads to high communication complexity. [ENTER] In fact, the best deterministic protocol which allows at most t corrupted parties needs O(nt) messages. In the following all mentioned broadcasts are reliable. Let us now take a closer look at some cryptographic basics. [ENTER] Deterministisches Protokoll (n Parteien, t < n sind korrumpiert):  Anzahl Nachrichten: O(nt) 6/29

7 Verteilung eines Geheimnisses:
2. Grundlagen – Shamir Secret Sharing Verteilung eines Geheimnisses: secret s4 s3 s1 s2 The technique of sharing a secret was developed by Adi Shamir in 1979 and is widely used in hundreds of protocols. On this slide, the basic process of sharing a secret is presented. The dealer Snoopy is holding a secret s, [ENTER] creates shares of it and [ENTER] distributes them amongst a group of participants P1, … P4, so that finally each is holding a share si of the secret. [ENTER] 7/29

8 Rekonstruktion des Geheimnisses:
2. Grundlagen – Shamir Secret Sharing Rekonstruktion des Geheimnisses: s1 s4 secret With this share in hand, one party alone can’t reconstruct the secret, but if a threshold of t shares is used together, here in the example we use a threshold of 3 the reconstruction of the secret is possible. [ENTER] Therefore three parties use their shares together and can then easily compute the secret. s2 s3 8/29

9 Rekonstruktion des Geheimnisses:
2. Grundlagen – Shamir Secret Sharing Rekonstruktion des Geheimnisses: s1 s4 secret Here you can see another example of how to reconstruct a secret. Such protocols with n shareholders and a threshold t are called (t,n)-secret sharing. [ENTER] s2 s3 9/29

10 Probleme bei Shamirs Secret Sharing Verfahren:
2. Grundlagen – Verifiable Secret Sharing Probleme bei Shamirs Secret Sharing Verfahren: secret s4 s3 s1 s2 The method from above has some drawbacks. Look at Snoopy. He owns a secret and creates 4 shares out of it. [ENTER] But now assume that the dealer Snoopy is corrupted. He can then easily corrupt the whole reconstruction process without ever being identified. This can be done by the dealer in distributing incorrect shares. [ENTER] 10/29

11 Probleme bei Shamirs Secret Sharing Verfahren:
2. Grundlagen – Verifiable Secret Sharing Probleme bei Shamirs Secret Sharing Verfahren: s1 s4 cretse As you can see on this slide, with these shares in hand a correct reconstruction of the secret is not possible. [ENTER] s2 s3 11/29

12 Probleme bei Shamirs Secret Sharing Verfahren:
2. Grundlage – Verifiable Secret Sharing Probleme bei Shamirs Secret Sharing Verfahren: s1 s4 cretse Lösung: Verifiable Secret Sharing A further problem is, that a participant can easily lie about its share, for example to gain access to other shares. [ENTER] Here as you can see, Charlie Brown is corrupted and uses instead of his correct share a false one. Using this one, reconstruction of the secret is not possible. To prevent both scenarios a so called verifiable secret sharing (vss) scheme can be used . Basically, this technique allows participants to easily recognize corrupt behaviour and disqualify false parties. The Feldman- and the Pedersen-scheme are two widely-used techniques to do verifiable secret sharing. Let us now move on to the distributed key generation. [ENTER] s3 s2 12/29

13 Ziel: Gemeinschaftliches Erzeugen von Schlüsseln
2. Grundlagen – Distributed Key Generation (DKG) Ziel: Gemeinschaftliches Erzeugen von Schlüsseln Keine Partei kennt den geheimen Schlüssel x Zur Erzeugung und Verteilung wird keine TTP benötigt x ist zufällig  notwendig für formale Sicherheitsbeweise In practice, a distributed key generation (DKG) protocol is a main component of every fully distributed threshold cryptosystem. [ENTER] It allows a set of n parties to jointly generate a pair of public and private keys without ever having to compute, reconstruct or store the secret at any one place and without the need of a trusted dealer. [ENTER] In my work I dealt with key generation protocols for discrete log based cryptosystems. Generally, the security of discrete log based cryptosystems is based on the so called discrete log assumption. It says, that for correctly chosen groups G it is hard to compute the discrete logarithm for a given number out of G. In this context, the word hard means, that it is infeasible to do the required work in polynomial-bounded time. [ENTER] A run of an instance of a DKG-protocol, results in the generation of a publicly known key y = gx and the sharing of the secret key x. Here, the value x is usually distributed using a VSS-scheme, so that finally every participant P_i holds a secret share s_i = f(i), but no party knows x on its own. 13/29

14 Schlüsselerzeugung für Kryptosysteme basierend auf DLOG
2. Grundlagen – Distributed Key Generation (DKG) Schlüsselerzeugung für Kryptosysteme basierend auf DLOG Partei Pi erhält: Öffentlicher Schlüssel: y = gx Teilstück: si = f(i) VSS  Verifikaitonswerte, um Korrektheit der Verteilung zu überprüfen. [GJKR99]: “Secure distributed key generation for Discrete-Log Based Cryptosystems” Dominierender Faktor des Kommunikationsaufwandes  Anzahl der zuverlässigen Broadcasts: O(nt) 14/29

15 Erzeugung & Verteilung von k Schlüsselpaaren für DLOG Kryptosysteme
3. k-JGRK – Ziele… Erzeugung & Verteilung von k Schlüsselpaaren für DLOG Kryptosysteme Jeder geheime Schlüssel ist genau einer Partei bekannt Alle Schlüssel werden gemäß einer Gleichverteilung gewählt Robust und sicher Warum nicht VSS? Korrumpierte Dealer können geheimen Schlüssel beliebig wählen Wieso ist die Zufälligkeit von Schlüsseln wichtig? Formale Sicherheitsbeweise 15/29

16 [GJ04] “Dining Cryptographers Revisited”
3. k-JGRK – Anwendungsgebiete… [GJ04] “Dining Cryptographers Revisited” Erzeugung von k zufälligen Schlüsseln für DC-Netz Autoren empfehlen Einsatz von GJKR-DKG  Wahrung der Zufälligkeit der Schlüssel für formalen Sicherheitsbeweis Aber: hoher Kommunikationsaufwand  O(knt) Broadcasts Erweiterungen am Protokoll sind notwendig Lösung: k-JGRK Direkter Ansatz  keine zusätzlichen Schritte notwendig Reduktion des Kommunikationsaufwandes auf O(kt), k ≥ n 16/29

17 Initial Phase k-JGRK Protokoll JGRK-Phase
1. GJKR-DKG: Verteilung von X für Schwellenwert ElGamal 2. GJKR-DKG: Commitments (1-mal ausführen) k-JGRK Protokoll JGRK-Phase This slide gives a brief insight of the k-DKG-protocol. This protocol is structured in two phases. [ENTER] The first phase, the so called initializing phase, is executed only once by the parties and consists of two instances of the New-DKG protocol of Gennaro. [ENTER] In the first instance, we use the result of the distributed key generation to create a shared secret key for an ElGamal threshold encryption. [ENTER] Basically, the second instance, is only needed for the formal proof of security. The results are used to create commitments. [ENTER] The second phase of the protocol is the DKG-phase. It is repeated k times and creates a random secret share for each party performing the protocol in a fully distributed way. So let us now take a look of some of the details of the repeated DKG-phase. [ENTER] (k-mal wiederholen) 17/29

18 (Details: nächsten Folien)
3. k-JGRK – Protokoll JGRK Phase In jeder Wiederholung agiert eine Partei Pi als Dealer Wiederholungen sind in 2 Schritte untergliedert: 1. Gemeinsame Erzeugung von xi für Pi: xi ist gemäß einer Gleichverteilung gewählt Nur Pi kennt xi Alle Parteien kennen den Verifikationswert Ai = gxi von xi Firstly, in each iteration of the DKG-phase a random value x is jointly generated for each party P_i. Furthermore, a main goal of this step is that, after step 1, only the party P_i, for who this iteration is executed knows the value x. So, let us now take a look at some details of this main component of this step: [ENTER] I will start with some notations, which I will write down on the board: Firstly, I define the set P…. After this detailed description, let me come back to the slides. [ENTER] The second step of the DKG-phase is the distribution of the secret x, which was generated in step 1 for the dealer party P_i. For the distribution P_i uses the Feldman Verifiable Secret Sharing scheme. Let me now move on to the correctness and secrecy properties of the k-DKG protocol. [ENTER] (Details: nächsten Folien) 2. Geheimnis xi wird gemäß des Feldman-VSS Verfahrens von Pi verteilt 18/29

19 Disqualifikation von Charlie Broadcaste commit2 r2 ЄR Zq
4. Beispiel: Erzeugung von x (1/4) (1) Disqualifikation von Charlie Broadcaste commit2 r2 ЄR Zq Broadcaste commit1 r1 ЄR Zq Disqualifikation von Charlie Voraussetzungen: commit1 commit1 commit1 commit2 commit2 commit2 P1 P2 Ergebnisse der Initialphase: Da mache ich nicht mit… Disqualifikation von Charlie Broadcast commit4 r3 ЄR Zq r4 ЄR Zq Alle Parteien kennen: Pi ist auf ri festgelegt. Das Commitment ist Unconditional Hiding. commit4 commit4 commit4 P3 P4 19/29

20 Garantiert, dass es sich beim Wert ri aus dem Commitment
4. Beispiel: Erzeugung von x (2/4) (2) z2 ЄR Zq z1 ЄR Zq Voraussetzungen: Ergebnisse der Initialphase: Alle Parteien kennen: Garantiert, dass es sich beim Wert ri aus dem Commitment um den zufällige Teil des Chiffretextes Ci handelt. Ungültiger Beweis Ausschluss z4 ЄR Zq 20/29

21 Zufälligkeit von Ftot kann formal bewiesen werden
4. Beispiel: Erzeugung von x (2/4) Nach (2) kann jede Partei das folgende Produkt berechnen: ElGamal ist multiplikativ homomorph  C ist Verschlüsselung von: Warum ist Ftot zufällig in G? rand ? Wenn das DDH-Problem in G schwierig ist, dann erhält ein Angreifer für gegebenen, öffentlichen Schlüssel Y und Chiffretext Ci einer ehrlichen Partei Pi keine Informationen über den zugehörigen Klartext Fi. Angreifer muss seinen Anteil “?” ohne Kentniss von “rand” wählen. Wieso? Zufälligkeit von Ftot kann formal bewiesen werden 21/29

22 Wesentlich für Sicherheit: Nur PD kennt â
4. Beispiel: Erzeugung von x (3/4) (3) â ЄR Zq Voraussetzungen: Â Â Ergebnisse der Initialphase: Alle Parteien kennen: Wesentlich für Sicherheit: Nur PD kennt â 22/29

23 Überprüfe Korrektheit Überprüfe Korrektheit (4)
4. Beispiel: Erzeugung von x (4/4) Überprüfe Korrektheit Überprüfe Korrektheit (4) Voraussetzungen: Ergebnisse der Initialphase: Benutze 2 Teil- entschlüsselungen Wi zur Rekonstruktion von Ftot := Decrypt(C) Überprüfe Korrektheit Alle Parteien kennen: 23/29

24 Jede Partei kennt den Verifikationswert A = gx von x:
4. Beispiel: Erzeugung von x (4/4) x ist zufällig: Nur PD kennt x: Jede Partei kennt den Verifikationswert A = gx von x: 24/29

25 Definition 1 (t-Korrektheit):
3. k-JGRK – Korrektheit Definition 1 (t-Korrektheit): k-JGRK ist t-korrekt, wenn für jeden qualifizierten Dealer PD mit geheimen Schlüssel x und öffentlichen Schhlüssel y=gx die folgenden Bedingungen gelten: (C1) Jede Teilmenge von t+1 ehrlichen Parteien kann den geheimen Schlüssel rekonstruieren. (C2) Alle ehrlichen Parteien besitzen einen identischen öffentlichen Schlüssel y=gx (C3) x wird zufällig aus Zq gewählt. (C4) Betrug führt zum Ausschluss Theorem 1 (t-Korrektheit): Wenn die DDH Annahme wahr ist, dann existiert kein probabilistischer, polynomiell zeitbeschränkter Angreifer mit höchstens t < n/2 Parteien unter Kontrolle, der die Korrektheitseigenschaften aus Definition 1 aufheben kann. 25/29

26 Definition 2 (t-Sicherheit):
3. k-JGRK – Sicherheit Definition 2 (t-Sicherheit): Wir bezeichnen k-JGRK als sicher, wenn kein probabilistischer, polynomiellzeitbeschränkter Angreifer AS existiert, der durch Teilnahme am Protokoll den geheimen Schlüssel x einer ehrlichen Partei berechnen kann. Theorem 2 (t-Korrektheit): Wenn die DL Annahme wahr ist, dann existiert kein polynomiell zeitbeschränkter Angreifer AS, der höchstens t < n/2 Parteien unter seiner Kontrolle hat. 26/29

27 Anzahl an Broadcasts: O(kt)
4. Zusammenfassung Anzahl an Broadcasts: O(kt) Jedes Geheimnis x ist nur einer Partei bekannt Alle Geheimnisse sind zufällig Fromale Beweise von Korrektheit und Sicherheit On this slide, I will sum up the results concerning the k-DKG protocol: [ENTER] Firstly, the protocol needs only O(kt) broadcasts. If the size of the set of parties is n, then we need O(nt) broadcasts to generate and share n secrets. [ENTER] Next, each qualified party knows exactly one secret explicitly. [ENTER] Furthermore, all secrets are randomly. [ENTER] And finally, the protocol satisfies the correctness and security properties. Let me now move on to the P2P-DKG-protocol. [ENTER] 27/29

28 4. Weiterführende Ansätze…
1. Steigerung der Kommunikationseffizienz durch probabilistische Protokolle? 2. Einsatz unserer Techniken für Kryptosystem, die nicht auf DLOG basieren (z.B. RSA, Paillier) At Eurocrypt 2004, John Canny and Stephen Sorkin present a solution for distributed key generation for large-scale networks. Their solution relies on a sparse evaluation matrix. With this technique they can reduce the communication and computation complexity, but loose a bit of security. Further their protocol is probabilistic and has a small failure probability. [ENTER] Until now we only used our techniques only for cryptosystems based on discrete logarithms. We want to figure out if the techniques can be used also for cryptosystems like RSA [ENTER]. 28/29

29 Fragen? ? ? ? ? http://www.logic-software.de/sfaust/
Kryptowochenende, 2. Juli 2006 Fragen? ? ? ? ? 29/29