Systems Architecture Blinding Signatures Joanna Ludmiła Ryćko, Wojciech Wójcikiewicz 29. Mai 2007

2 May Systems Architecture Was ist blinde Unterschrift? „Blinde Signatur ist eine Art digitale Unterschrift, bei der der Unterschreibende es nicht sieht, was er unterschreibt.“

Systems Architecture

4 May Systems Architecture Wozu blind signature?  Elektronische Wahlen -I-Voting / Internetwahl / Remote E-Voting -Deutschland: „Forschungsgruppe Internetwahlen“ » System „i-vote“ -Wahlen zum Studierendenparlament an der Universität Osnabrück, Vorstandswahlen des Weimar Kreises, USA: -System „SERVE“ – 2004 Präsidentenwahl  Elektronische Zahlungssysteme -E-Geld: Kartengeld vs. Netzgeld -DigiCash (Dr David Chaum)

5 May Systems Architecture Fallstudie: Wahlsystem Anforderungen  Korrektheit der Unterschrift  Anonymität: blindness und untraceability  Fälschungssicherheit  Wahlberechtigungsprüfung  eine Stimme pro Person zugelassen -Nichtvermehrbarkeit  Individuelle Verifizierbarkeit  Universelle Verifizierbarkeit  geringe Kommunikations- und Rechenkomplexität » verschiedene Algorithmen

6 May Systems Architecture Wahlen – Basisidee

7 May Systems Architecture Formaler Ablauf (RSA)  p und q – zwei große Primzahlen, vom Signierer (z. B. Wahlamt) geheim gehalten  n = p·q  (e,n) – öffentlicher Schlüssel des Signierers  d – privater Schlüssel des Signierers  e·d ≡ 1 mod (p–1)·(q–1)  m – Nachricht (z. B. Stimme), die signiert werden soll  r – blinding factor, z. B. Briefumschlag  α = r e ·m mod n – blinded message  t = α d mod n – unterschriebene blinde Nachricht  s = t·r -1 mod n – Signatur  (m,s) wird publiziert  s e ≡ m mod n – jeder kann die Legitimität der Unterschrift prüfen

8 May Systems Architecture Eigenschaften  Digitale Signatur: -Jeder kann die Authentizität der Signatur nachprüfen -Signierer kann seine Signatur nicht leugnen -Sicherheitsbasis – Schwierigkeit der Faktorisierung bzw. Lösung diskreter Logarithmen -die Unterschrift kann nicht nachgebildet werden  Blinde Signatur: -Signierer weiß nichts über das Verhältnis von „Alice“ und der Nachricht » untraceability

9 May Systems Architecture Fallstudie: Zahlungssystem Anforderungen  Kontrolle und Sicherheit der Zahlung  Fälschungssicherheit  Anonymität des Zahlers  Echtheit des Geldes verifizierbar  Unter Umständen die Identität des Empfängers prüfbar

10 May Systems Architecture Digitale Münze (Onlineprotokoll)  keine Identifizierungsnummer einer Münze Nachteile:  der Empfänger weiß nicht, ob die Münze „Originalmünze“ ist, deshalb muss bei jeder Münze eine Anfrage an die Bank gestellt werden » hohe Netzlast » praktisch nicht realisierbar  Anonimität der Münzen » Geldwäsche/Erpressungen nicht zurückverfolgbar  Problem des Wechselgeldes » Münze in Wert von 10€ / Einkauf kostet 9,99€

11 May Systems Architecture Digitale Schecks (Offlineprotokoll)  der Händler sammelt alle Schecks von einem Kunde und reicht sie gebundelt bei der Bank ein  Einreichen von gefälschten Schecks nicht zu verhindern  ein Betrug (eines Kunden/Händlers) aufdeckbar Anforderungen:  Scheckdeckung  Fälschungssicherheit  Anonymität des Zahlungsverkehrs

12 May Systems Architecture Protokoll von Chaum / Fiat / Naor  Alice stellt ihre Person als eine Zahl I dar (z. B. ein Hashwert)  R – sehr lange Zufallszahl – Schecknummer  (a i ), (b i ), (c i ) – gleichlange Zufallszahlenfolgen, vom gleichen Datentyp wie I  (x i ), (y i ), x i = h(a i, b i ), y i = h(a i +I, c i ) h – Hashfunktion  N Schecks: Betrag, R, (x i ) und (y i ), wobei (1 < i < N)  Bank wählt N-1 Schecks, Alice muss sie sowie (a i ), (b i ) und (c i ) und Blindfaktor offenlegen  Bank kann (x i ) und (y i ) prüfen; alles in Ordnung – wird der N-te Scheck unterschrieben

13 May Systems Architecture Protokoll von Chaum / Fiat / Naor II  Alice kann mit dem unterschriebenen Scheck bei Bob bezahlen  Sie sendet: den Betrag, Schecknr R, den Hashwert des Schecks und die Signatur der Bank an Bob  Er prüft die Unterschrift der Bank mit deren öffentlichen Schlüssel.  Bob sendet eine N-Bit-Zahlenfolge z i an Alice, die für jedes Bit entweder a i, b i und y i (falls z i = 1) oder (a i + I), c i und x i (falls z i =0) verraten.  Bob kann sich nun die Zahlenfolgen (x i ) und (y i ) errechnen und somit den Hashwert des Schecks prüfen.  Zuletzt: -bekommt Alice ihre bestellte Ware, -gibt Bob ihre alle Daten an die Bank weiter, -die diese speichert -und den entsprechenden Betrag auf sein Konto gutschreibt

14 May Systems Architecture Protokoll von Chaum / Fiat / Naor III Vorteile:  Anonymität von Alice gewährleistet  Betrug von Alice wird aufgedeckt  Betrug von Bob wird aufgedeckt Zusatzinformation: Falls doch mal die Schecknummern zweier Kunden gleich sind, ergeben sich sehr wahrscheinlich verschiedene I Restprobleme:  Sicherheitsrisiko bei weiteren beteiligten  Netzbelastung sehr hoch  Einnahmen von Bob nicht anonym  Wechselgeldproblem

15 May Systems Architecture Erweiterungsmöglichkeiten  Mehrere Teilnehmer  Dezentralisiert  Feinere Aufteilung

16 May Systems Architecture Fazit  Relativ neues Forschungsgebiet in der Kryptologie  Anonymität sichergestellt  Sicherheit und Kontrolle

17 May Systems Architecture Quellen  Blind signatures for untraceable payments, D. Chaum /HTML/PDF/C82/199.PDF  Untraceable Electronic Cash, Chaum, Fiat, Naor, Abgerufen: , 23:20  Untraceable Blind Signature Schemes Based on Discrete Logarithm Problem (2003), Cheng-Chi Lee, Wei-Pang Yang coll=GUIDE&dl=&CFID= &CFTOKEN=  Elektronisches Geld und elektronische Wahlen, Claudia Ernst, Lehre/WS /PS/index.html  Blind signature. ( ). In Wikipedia, The Free Encyclopedia. Abgerufen: 16:50, , oldid=

18 May Systems Architecture Quellen II  DigiCash. ( ). In Wikipedia, The Free Encyclopedia. Abgerufen 22:22, ,  I-Voting (6. Mai 2007). In: Wikipedia, Die freie Enzyklopädie. Abgerufen: 28. Mai 2007, 22:26  JavaApplet, Wagner 2002,