In diesem Kapitel geben wir eine hochrangige Beschreibung der Electronic-Cash-Protokolle im Hinblick auf grundlegende Authentifizierungsmechanismen. Wir beginnen mit der Beschreibung dieser Mechanismen, die auf Public-Key-Kryptographie basieren. Dann bauen wir das Protokoll schrittweise auf, um die Exposition zu erleichtern. Wir beginnen mit einem vereinfachten Schema, das keine Anonymität bietet. Wir integrieren dann die Zahlungsunverfolgbarkeitsfunktion und schließlich die Zahlungsanonymität. Das Ergebnis wird ein vollständiges Electronic-Cash-Protokoll sein.
Wir beginnen mit der Diskussion der grundlegenden Public-Key-Verschlüsselungstechniken, auf denen die Electronic-Cash-Implementierungen basieren.
Einweg-Funktionen.
Eine Einwegfunktion ist eine Korrespondenz zwischen zwei Sets, die effizient in eine Richtung berechnet werden kann, aber nicht in die andere. Mit anderen Worten, die Funktion f ist einseitig, wenn es einfach ist, T = f(S) zu berechnen.
Aber nur für T gilt, S ist es schwierig zu finden. Die Elemente sind typischerweise Zahlen, könnten aber auch z.B. Punkte auf einer elliptischen Kurve sein; siehe[10].
Schlüsselpaare.
Wenn f eine Einwegfunktion ist, dann ist ein Schlüsselpaar ein Paar S, das in irgendeiner Weise über f verbunden ist. Wir nennen S den geheimen Schlüssel und T den öffentlichen Schlüssel. Wie die Namen schon andeuten, behält jeder Benutzer seinen geheimen Schlüssel für sich und stellt seinen öffentlichen Schlüssel allen zur Verfügung. Der geheime Schlüssel bleibt auch dann geheim, wenn der öffentliche Schlüssel bekannt ist, denn die Einweg-Eigenschaft von f versichert, dass T nicht aus S berechnet werden kann.
Alle Public-Key-Protokolle verwenden Schlüsselpaare.
Aus diesem Grund wird Public-Key-Kryptographie oft als asymmetrische Kryptographie bezeichnet. Konventionelle Kryptographie wird oft als symmetrische Kryptographie bezeichnet, da man mit dem privaten Schlüssel sowohl verschlüsseln als auch entschlüsseln kann, aber nicht ohne ihn auskommt.
Signatur und Identifikation.
In einem Public-Key-System identifiziert sich ein Benutzer, indem er nachweist, dass er seinen geheimen Schlüssel kennt, ohne ihn zu enthüllen. Dies geschieht, indem man eine Operation mit dem geheimen Schlüssel durchführt, den jeder mit dem öffentlichen Schlüssel überprüfen oder rückgängig machen kann. Dies wird als Identifikation bezeichnet. Wenn man sowohl eine Nachricht als auch den geheimen Schlüssel verwendet, führt man eine digitale Signatur auf der Nachricht durch. Die digitale Signatur spielt die gleiche Rolle wie eine handschriftliche Unterschrift: Sie identifiziert den Verfasser der Nachricht in einer nicht zu verleugnenden Weise und bestätigt die Integrität der Nachricht.
Sicheres Hashing.
Eine Hash-Funktion ist eine Abbildung von allen möglichen Zeichenfolgen von Bits beliebiger Länge auf eine Bitfolge fester Länge.
Solche Funktionen müssen oft kollisionsfrei sein, d.h. es muss rechnerisch schwierig sein, zwei Eingänge zu finden, die den gleichen Wert haben. Wenn eine Hash-Funktion sowohl einseitig als auch kollisionsfrei ist, spricht man von einem sicheren Hash.
Die häufigste Verwendung von sicheren Hash-Funktionen ist die digitale Signatur. Nachrichten können in beliebiger Größe vorliegen, aber ein bestimmter Public-Key-Algorithmus erfordert die Arbeit in einem Satz fester Größe. Man hascht also die Nachricht und signiert den sicheren Hash und nicht die Nachricht selbst. Der Hash muss einseitig sein, um Signaturfälschungen zu verhindern, d.h. eine gültige Signatur einer Nachricht ohne Verwendung des geheimen Schlüssels zu konstruieren.4 Der Hash muss kollisionsfrei sein, um eine Ablehnung zu verhindern, d.h. die Ablehnung, eine Nachricht signiert zu haben, indem eine andere Nachricht mit demselben Hash erzeugt wird.
__________
4 Beachten Sie, dass die Fälschung von Token nicht dasselbe ist wie die Fälschung von Unterschriften. Die digitale Signatur der Bank zu fälschen, ohne den geheimen Schlüssel zu kennen, ist eine Möglichkeit, eine Fälschung von Wertmarken zu begehen, aber nicht die einzige. Ein Bankangestellter oder Hacker könnte sich beispielsweise den geheimen Schlüssel der Bank "leihen" und ein Token rechtsgültig signieren. Dieses Schlüsselkompromiss-Szenario wird in 5.3 diskutiert.
Wir präsentieren jetzt ein vereinfachtes elektronisches Kassensystem ohne Anonymitätsmerkmale.
Abhebung:
Alice sendet eine Auszahlungsanfrage an die Bank.
Die Bank bereitet eine elektronische Münze vor und signiert sie digital.
Die Bank schickt Alice eine Münze und belastet ihr Konto.
Zahlung/Einzahlung:
Alice gibt Bob die Münze.
Bob kontaktiert Bank5 und schickt Münzen.
Die Bank prüft die digitale Signatur der Bank.
Die Bank prüft, ob die Münze noch nicht ausgegeben wurde.
Die Bank konsultiert ihre Auszahlungsunterlagen, um die Auszahlung von Alice zu bestätigen. (optional)
Die Bank gibt die Münze in die Spent-Münzdatenbank ein.
Die Bank schreibt Bobs Konto gut und informiert Bob.
Bob gibt Alice die Ware.
__________
5 Man sollte bedenken, dass der Begriff "Bank" sich auf das Finanzsystem bezieht, das die Münzen ausgibt und löscht. Die Bank kann z.B. eine Kreditkartenfirma oder das gesamte Bankensystem sein. Im letzteren Fall könnten Alice und Bob getrennte Banken haben. Wenn das so ist, dann ist das "Deposit"-Verfahren etwas komplizierter: Bobs Bank kontaktiert Alices Bank, "kassiert" die Münze und legt das Geld auf Bobs Konto.
Abhebung:
Alice sendet eine Auszahlungsanfrage an die Bank.
Die Bank bereitet eine elektronische Münze vor und signiert sie digital.
Die Bank schickt Alice eine Münze und belastet ihr Konto.
Bezahlung:
Alice gibt Bob die Münze.
Bob verifiziert die digitale Signatur der Bank. (optional)
Bob gibt Alice die Ware.
Einzahlung:
Bob schickt Münzen an die Bank.
Die Bank prüft die digitale Signatur der Bank.
Die Bank prüft, ob die Münze noch nicht ausgegeben wurde.
Die Bank konsultiert ihre Auszahlungsunterlagen, um die Auszahlung von Alice zu bestätigen. (optional)
Die Bank gibt die Münze in die Spent-Münzdatenbank ein.
Die Bank schreibt Bobs Konto gut.
Die oben genannten Protokolle verwenden digitale Signaturen, um Authentizität zu erreichen. Die Echtheitsmerkmale hätten auf andere Weise erreicht werden können, aber wir müssen digitale Signaturen verwenden, um die Anonymitätsmechanismen, die wir jetzt hinzufügen werden, zu berücksichtigen.
In diesem Abschnitt modifizieren wir die oben genannten Protokolle, um die Unauffindbarkeit von Zahlungen zu berücksichtigen. Dazu ist es notwendig, dass die Bank nicht in der Lage ist, eine bestimmte Auszahlung mit einer bestimmten Einzahlung zu verknüpfen.6 Dies geschieht durch eine spezielle Art der digitalen Signatur, die als Blindunterschrift bezeichnet wird.
Wir werden Beispiele für Blindsignaturen in 3.2 geben, aber im Moment geben wir nur eine Beschreibung auf hoher Ebene. Im Entnahmeschritt ändert der Benutzer die zu signierende Nachricht mit einer zufälligen Menge. Dieser Schritt wird als "Blenden" der Münze bezeichnet, und die Zufallsmenge wird als Blendenfaktor bezeichnet. Die Bank signiert diesen zufällig aussehenden Text, und der Benutzer entfernt den Blindfaktor. Der Benutzer verfügt nun über eine legitime elektronische Münze, die von der Bank signiert wurde. Die Bank wird diese Münze sehen, wenn sie zur Einzahlung eingereicht wird, aber sie wird nicht wissen, wer sie abgehoben hat, da die zufälligen Blindfaktoren der Bank unbekannt sind. (Offensichtlich wird es nicht mehr möglich sein, die Prüfung der Auszahlungssätze durchzuführen, die ein optionaler Schritt in den ersten beiden Protokollen war.)
Beachten Sie, dass die Bank nicht weiß, was sie im Auszahlungsschritt unterschreibt. Dies führt die Möglichkeit ein, dass die Bank etwas anderes unterschreibt, als das, was sie zu unterzeichnen beabsichtigt. Um dies zu verhindern, legen wir fest, dass die digitale Signatur einer Bank mit einem bestimmten geheimen Schlüssel nur als Berechtigung zur Auszahlung eines festen Betrags gilt. Zum Beispiel könnte die Bank einen Schlüssel für eine Auszahlung in Höhe von $10 haben, einen anderen für eine Auszahlung in Höhe von $50 und so weiter.7
_________
6 Um eine der beiden Anonymitätsfunktionen zu erreichen, ist es natürlich notwendig, dass der Pool der elektronischen Münzen groß ist.
7 Man könnte das Konzept der "blinden Unterschrift" auch auf interaktive Protokolle ausdehnen, bei denen beide Parteien zufällige Elemente zur zu signierenden Botschaft beitragen. Ein Beispiel dafür ist die "randomisierte Blindsignatur", die im Ferguson-Schema, das in 3.3 diskutiert wird, auftritt.
Abhebung:
Alice kreiert eine elektronische Münze und blendet sie.
Alice schickt die geblendete Münze mit einer Auszahlungsanfrage an die Bank.
Die Bank signiert die geblendete Münze digital.
Die Bank schickt Alice die unterschriebene Blindmünze und belastet ihr Konto.
Alice macht die signierte Münze unblind.
Zahlung/Einzahlung:
Alice gibt Bob die Münze.
Bob kontaktiert Bank und schickt Münzen.
Die Bank prüft die digitale Signatur der Bank.
Die Bank prüft, ob die Münze noch nicht ausgegeben wurde.
Die Bank gibt die Münze in die Spent-Münzdatenbank ein.
Die Bank schreibt Bobs Konto gut und informiert Bob.
Bob gibt Alice die Ware.
Abhebung:
Alice kreiert eine elektronische Münze und blendet sie.
Alice schickt die geblendete Münze mit einer Auszahlungsanfrage an die Bank.
Die Bank signiert die geblendete Münze digital.
Die Bank schickt Alice die unterschriebene Blindmünze und belastet ihr Konto.
Alice macht die signierte Münze unblind.
Bezahlung:
Alice gibt Bob die Münze.
Bob verifiziert die digitale Signatur der Bank. (optional)
Bob gibt Alice die Ware.
Einzahlung:
Bob schickt Münzen an die Bank.
Die Bank prüft die digitale Signatur der Bank.
Die Bank prüft, ob die Münze noch nicht ausgegeben wurde.
Die Bank gibt die Münze in die Spent-Münzdatenbank ein.
Die Bank schreibt Bobs Konto gut.
Wir gehen nun den letzten Schritt und modifizieren unsere Protokolle, um die Anonymität der Zahlung zu erreichen. Die ideale Situation (aus Sicht der Datenschutzbeauftragten) ist, dass weder der Zahler noch der Zahlungsempfänger die Identität des anderen kennen sollten. Dadurch werden Remote-Transaktionen mit electronic cash völlig anonym: Niemand weiß, wo Alice ihr Geld ausgibt und wer sie bezahlt.
Es stellt sich heraus, dass dies zu viel verlangt ist: Es gibt in einem solchen Szenario keine Möglichkeit für den Verbraucher, eine unterschriebene Quittung zu erhalten. So sind wir gezwungen, uns mit der Anonymität des Zahlers zu begnügen.
Wenn die Zahlung online erfolgen soll, können wir das Protokoll Nr. 3 verwenden (natürlich implementiert, um die Anonymität des Zahlers zu gewährleisten). Im Offline-Fall stellt sich jedoch ein neues Problem. Wenn ein Händler versucht, eine zuvor ausgegebene Münze einzuzahlen, wird er von der Bank abgelehnt, aber keiner weiß, wer der Mehrfachausgeber war, da sie anonym war. Daher ist es notwendig, dass die Bank in der Lage ist, einen Mehrfachausgeber zu identifizieren. Diese Funktion sollte jedoch die Anonymität der gesetzestreuen Nutzer wahren.
Die Lösung besteht darin, dass der Zahlungsschritt verlangt, dass der Zahler zusätzlich zu seiner elektronischen Münze eine Art Identifizierungsinformation hat, die er mit dem Zahlungsempfänger teilen muss. Diese Informationen sind so aufgeteilt, dass jedes einzelne Stück nichts über die Identität von Alice aussagt, aber zwei beliebige Stücke genügen, um sie vollständig zu identifizieren.
Diese Informationen werden während des Entnahmeschrittes erzeugt. Das Abhebungsprotokoll beinhaltet einen Schritt, bei dem die Bank überprüft, ob die Informationen vorhanden sind und mit Alice und der jeweiligen zu erstellenden Münze übereinstimmen. (Um die Anonymität des Zahlers zu wahren, wird die Bank die Informationen nicht wirklich sehen, sondern nur überprüfen, ob sie vorhanden sind. Alice trägt die Information zusammen mit der Münze, bis sie sie ausgibt.
Beim Bezahlvorgang muss Alice Bob einen Teil dieser Informationen offenbaren. (So kann nur Alice die Münze ausgeben, da nur sie die Informationen kennt.) Diese Enthüllung erfolgt über ein Challenge-Response-Protokoll. In einem solchen Protokoll schickt Bob Alice eine zufällige "Challenge"-Menge und als Antwort gibt Alice eine identifizierende Information zurück. ) Beim Einzahlungsschritt wird das aufgedeckte Stück zusammen mit der Münze an die Bank geschickt. Wenn alles so läuft, wie es sollte, werden die identifizierenden Informationen niemals auf Alice zeigen. Sollte sie die Münze jedoch zweimal ausgeben, erhält die Bank letztendlich zwei Kopien derselben Münze, jede mit einem Stück Identifikationsinformation. Wegen der Zufälligkeit im Challenge-Response-Protokoll werden diese beiden Teile unterschiedlich sein. Auf diese Weise wird die Bank in der Lage sein, sie als Mehrfachausgeberin zu identifizieren. Da nur sie selbst identifizierende Informationen ausgeben kann, wissen wir, dass ihre Münze nicht kopiert und von jemand anderem wieder ausgegeben wurde.
Abhebung:
Alice entwirft eine elektronische Münze, einschließlich Identifikationsinformationen.
Alice blendet die Münze.
Alice schickt die geblendete Münze mit einer Auszahlungsanfrage an die Bank.
Die Bank prüft, ob die identifizierenden Informationen vorhanden sind.
Die Bank signiert die geblendete Münze digital.
Die Bank schickt Alice die unterschriebene Blindmünze und belastet ihr Konto.
Alice macht die signierte Münze unblind.
Bezahlung:
Alice gibt Bob die Münze.
Bob verifiziert die digitale Signatur der Bank.
Bob schickt Alice eine Herausforderung.
Alice schickt Bob eine Antwort (die ein Stück Identifikationsinfo enthüllt).
Bob überprüft die Antwort.
Bob gibt Alice die Ware.
Einzahlung:
Bob schickt Münzen, Herausforderungen und Antworten an die Bank.
Die Bank prüft die digitale Signatur der Bank.
Die Bank prüft, ob die Münze noch nicht ausgegeben wurde.
Die Bank gibt Münzen, Herausforderungen und Antworten in die Spent-Münzdatenbank ein.
Die Bank schreibt Bobs Konto gut.
Beachten Sie, dass Bob in diesem Protokoll die Unterschrift der Bank überprüfen muss, bevor er Alice die Ware übergibt. Auf diese Weise kann Bob sicher sein, dass er entweder bezahlt wird oder dass er Alice's Identität als Mehrfachspender erfährt.