23.November2011 wilhelm@math.hu-berlin.de PaulWilhelm ElektronischesGeld

(1)

Ideales Elektronisches Geld ECash nach Chaum Bitcoin Fazit Literatur

Elektronisches Geld

Paul Wilhelm wilhelm@math.hu-berlin.de

Humboldt-Universit¨at zu Berlin

23. November 2011

Paul Wilhelm (HU Berlin) Elektronisches Geld 23. November 2011 1 / 31

(2)

Gliederung

1 Ideales Elektronisches Geld Ideales Elektronisches Geld

2 ECash nach Chaum Vorbemerkungen ECash Protokoll

Variante 1 Variante 2 Variante 3

Fazit ECash

3 Bitcoin Bitcoin

4 Fazit Fazit

5 Literatur

(3)

Gliederung

Fazit ECash

3 Bitcoin Bitcoin

4 Fazit Fazit

5 Literatur

(4)

Gliederung

Fazit ECash

3 Bitcoin Bitcoin

4 Fazit Fazit

5 Literatur

(5)

Gliederung

Fazit ECash

3 Bitcoin Bitcoin

4 Fazit Fazit

5 Literatur

(6)

Gliederung

Fazit ECash

3 Bitcoin Bitcoin

4 Fazit Fazit

5 Literatur

(7)

Ideales Elektronisches Geld

Kriterien von Okamoto und Ohta

Okamoto und Ohta (1991) haben sechs Kriterien f¨ur ideales elektronische Geld aufgestellt (erg¨anzt nach Schmidt, Schunter und Weber (1999)):

1 Unabh¨angigkeit

keine Bindung an bestimmte (manipulationsgesch¨utzte) Hardware

¨uber unsichere Netzwerke transferierbar dezentral?

2 Sicherheit

F¨alschungssicherheit

Verhinderung von Mehrfachverwendungdouble spendingdurch Online-Abgleich oder durch Speicherung eingelöster Münzen und nachträglichen Nachweis bzw. Identifizierung der Betrüger Unwiderrufbarkeit

Wiederherstellbarkeit bei Verlust?

robust (skalierbar, DoS)

(8)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(9)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(10)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(11)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(12)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(13)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(14)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(15)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(16)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(17)

Kriterien von Okamoto und Ohta

1 Unabh¨angigkeit

2 Sicherheit

(18)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

Zahlungen d¨urfen nicht zur¨uckverfolgbar sein.

Unverkettbarkeit verschiedener Zahlungen eines Nutzers

nur bei M¨unzgeld ohne Einschr¨ankungen gegeben (wheresgeorge.com )

4 offline Verwendbarkeit

5 Ubertragbarkeit¨

6 Teilbarkeit (Wechselgeldproblem)

(19)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(20)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(21)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(22)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(23)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(24)

Kriterien von Okamoto und Ohta

3 Anonymit¨at

5 Ubertragbarkeit¨

(25)

Vorbemerkungen ECash

Vorbemerkungen

Chaum schlug 1983 als erster nicht zur¨uckverfolgbare Zahlungen mittels blinder Signaturen vor.

Chaum, Fiat und Naor ver¨offentlichen 1990 Paper das Grundlage f¨ur ECash ist.

ECash nur in Testphase, 1998 DigiCash bankrott (http://cryptome.org/jya/digicrash.htm)

Aktuell: effizientere und komplexere Verfahren (Camenisch und Lysyanskaya 2006, Au, Susilu und Mu 2008)

(26)

Vorbemerkungen

(27)

Vorbemerkungen

(28)

Vorbemerkungen

(29)

Vorbemerkungen

Unterschied zum original Paper, didaktisch aufbereitet (siehe Schneier bzw. Goldwasser und Bellare)

blinde RSA Signaturen werden durch einen Umschlag mit Kohlepapier symbolisiert

mehrere Varianten, schrittweiser Aufbau verdeutlicht Schutzziele

(30)

Vorbemerkungen

(31)

Vorbemerkungen

(32)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

Drei Parteien Protokoll bestehend aus Bank, Nutzer und H¨andler.

Geld kann nicht an andere Nutzer

transferiert werden (’keine ¨Ubertragbarkeit’).

drei Phasen (abheben, bezahlen und einl¨osen)

Bezahlung soll ohne Interaktion mit der Bank stattfinden (’offline’).

Es muss passend gezahlt werden.

(33)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

(34)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

(35)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

(36)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

(37)

Struktur

H¨andler

einl¨osen

44

4444 4444 4444 444

Bank

abheben

Nutzer

bezahlen

OO

(38)

Protokoll

Variante 1 (’cut and choose’)

abheben

Der Nutzer erstelltn anonyme Schecks, indem er jeden in einen Umschlag mit Kohlepapier legt. Auf jedem Scheck ist vermerkt:

der Nennwert von 1000 EUR.

Der Nutzer übergibt die verschlossenen Umschläge an die Bank. Die Bank lässt (n−1) zufällig gewählte Umschläge öffnen und

unterschreibt den verbleibenden unge¨offneten Umschlag blind. Die Bank sendet den Umschlag zur¨uck an den Nutzer.

Der Nutzer ¨offnet den Umschlag und besitzt einen g¨ultigen Scheck.

(39)

Protokoll

Variante 1 (’cut and choose’)

abheben

(40)

Protokoll

Variante 1 (’cut and choose’)

abheben

(41)

Protokoll

Variante 1 (’cut and choose’)

abheben

(42)

Protokoll

Variante 1 (’cut and choose’)

abheben

(43)

Protokoll

Variante 1 (’cut and choose’)

abheben

(44)

Protokoll

Variante 1 (’cut and choose’)

bezahlen

Der Nutzer bezahlt beim H¨andler mit dem Scheck:

Der Händler überprüft die Gültigkeit des Scheck mithilfe der Unterschrift

(45)

Protokoll

Variante 1 (’cut and choose’)

bezahlen

Der Händler überprüft die Gültigkeit des Scheck mithilfe der Unterschrift

(46)

Protokoll

Variante 1 (’cut and choose’)

einl¨osen

Der H¨andler l¨ost den Scheck bei der Bank ein:

Die Bank ¨uberpr¨uft die Unterschrift auf dem Scheck.

Die Bank z¨ahlt 1000 EUR dem H¨andler aus

Problem: Nur der Nennwert des Schecks wird sichergestellt. ’double spending’ ist m¨oglich.

(47)

Protokoll

Variante 1 (’cut and choose’)

einl¨osen

(48)

Protokoll

Variante 1 (’cut and choose’)

einl¨osen

(49)

Protokoll

Variante 1 (’cut and choose’)

einl¨osen

(50)

Protokoll

Variante 1 (’cut and choose’)

einl¨osen

(51)

Protokoll

Variante 2 (kein ’double spending’)

abheben

der Nennwert von 1000 EUR

und eine ausreichend lange pseudozuf¨allige Seriennummer.

Der Nutzer Übergibt die Umschläge an die Bank. Die Bank läßt (n−1) zufällig gewählte Umschläge öffnen und unterschreibt den verbleibenden ungeöffneten Umschlag blind. Die Bank sendet den Umschlag zurück an den Nutzer.

(52)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(53)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(54)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(55)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(56)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(57)

Protokoll

Variante 2 (kein ’double spending’)

abheben

(58)

Protokoll

Variante 2 (kein ’double spending’)

bezahlen

Der Händler überprüft die Gültigkeit des Scheck mithilfe der Unterschrift.

(59)

Protokoll

Variante 2 (kein ’double spending’)

bezahlen

(60)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

Die Bank überprüft ob schon ein Scheck mit der gleichen Seriennummer eingelöst wurde. Wenn ja, bricht sie den Vorgang wegen Betruges ab. Wenn nein, vermerkt die Bank den Scheck als eingelöst und speichert die Seriennummer

Problem: Es ist nicht klar ob Nutzer oder H¨andler betrogen haben.

(61)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

(62)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

(63)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

(64)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

(65)

Protokoll

Variante 2 (kein ’double spending’)

einl¨osen

(66)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

eine ausreichend lange pseudozuf¨allige Seriennummer und die Hash-Werteh(I₁^l),h(I₁^r), ...,h(I_m^l),h(I_m^r). Wobei die Identit¨atspaare (I_i^l,I_i^r) jeweils durch Secret Splitting einer IdentifikationsnummerI entstehen.

Der Nutzer übergibt die Umschläge an die Bank. Die Bank läßt (n−1) zufällig gewählte Umschläge öffnen, die zugehörigen (I_i^l,I_i^r)_i

¨

ubermittelnund unterschreibt den verbleibenden unge¨offneten Umschlag blind. Sendet den Umschlag zur¨uck an den Nutzer.

(67)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

¨

(68)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

¨

(69)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

¨

(70)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

¨

(71)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

abheben

¨

(72)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

bezahlen

Der H¨andler sendet an den Nutzer einen zuf¨alligen Bitstring (b1, ...,bm)∈_R {l,r}^m.

Der Nutzer sendet an den Händler die IdentitätsfolgeI₁^b¹, ...,I_m^b^m. Der Händler überprüft obh(I₁^b¹), ...,h(I_m^b^m) auf dem Scheck vermerkt ist und fügt die Identifikationsfolge dem Scheck hinzu.

(73)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

bezahlen

(74)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

bezahlen

(75)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

bezahlen

(76)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

einl¨osen

Uberpr¨¨ uft ob schon ein Scheck mit der gleichen Seriennummer eingel¨ost wurde.

Wenn ja, bricht sie den Vorgang wegen Betruges ab.Falls die

Identitätsfolge gleich ist oder nicht zum Scheck passt, hat der Händler betrogen. Wenn nicht, kann die Bank die Identität des Nutzers berechnen.

Wenn nein, vermerkt die Bank den Scheck als eingel¨ost und speichert die Seriennummerund die Identit¨atsfolge.

(77)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

einl¨osen

(78)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

einl¨osen

(79)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

einl¨osen

(80)

Protokoll

Variante 3 (Identifizierung des Betr¨ uger)

einl¨osen