DE69632482T2

DE69632482T2 - Elektronisches geldsystem ohne ursprungserkennung

Info

Publication number: DE69632482T2
Application number: DE69632482T
Authority: DE
Inventors: R. Daniel SIMON
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1995-08-29
Filing date: 1996-08-29
Publication date: 2005-05-12
Anticipated expiration: 2016-08-30
Also published as: WO1997009688A3; DE69632482D1; WO1997009688A2; CA2229206A1; ATE266919T1; EP0873615B1; US5768385A; EP0873615A2; JP2000503786A; CA2229206C; EP0873615A4

Description

Die Erfindung bezieht sich generell auf elektronische Geldsysteme.
Das instinktive Endziel eines elektronischen Geldsystems ist, die besten Merkmale realen Gelds (Geheimhaltung, Anonymität, Fälschungssicherheit) mit den besten Merkmalen von E-Commerce (Geschwindigkeit, Leichtigkeit und potenzielle Sicherheit von Transport und Lagerung) zu kombinieren. Das grundlegende Problem beim Versuch ein anonymes elektronisches Geldsystem zu implementieren, lässt sich aber leicht nennen: Wenn der Besitzer bzw. die Besitzerin einer elektronischen "Münze" nicht in zwei aufeinander folgenden Transaktionen identifiziert wird, wie soll dann er bzw. sie daran gehindert werden, so zu handeln, als ob die erste Transaktion nie geschah und die gleiche Münze erneut auszugeben? Die erste vorgeschlagene Lösung dieses Problems wurde von Chaum, Fiat und Naor (siehe D. Chaum, A. Fiat und M. Naor, Untraceable Electronic Cash, Prot. CRYPTO '88, Springer-Verlag (1990), pp. 319–327.) vorgelegt und beruhte auf der Prämisse, dass es ausreichend wäre, ein solches „doppeltes Ausgeben", nach zweimaligem Vorlegen derselben „elektronischen Münze" bei der Zentralbank, zu erkennen und den Ausgebenden zu identifizieren. Diese Prämisse wurde ebenso mehrere Male verwendet, jeweils mit dem Vorteil, dass die Bank nicht in jede Transaktion verwickelt sein braucht. Konkret gesagt, hat diese Prämisse aber enorme Nachteile. Betrügerische Transaktionen werden erst lange nach Stattfinden festgestellt und, wenn der Täter zuversichtlich sein kann, nicht vor Gericht gebracht zu werden (entweder dadurch, dass kein Zugriff auf ihn möglich ist oder er es schafft, Identität und Geld von jemand anderem zu benutzen), dann kann er oder sie beliebig doppelt ausgeben.
Wenn aber derartige betrügerische Verwendung von elektronischem Geld verhindert werden soll, dann muss irgendeine Behörde irgendwie in jede Transaktion verwickelt sein, sowie diese stattfindet, um Zielpersonen von Doppelausgabe erkennen und alarmieren zu können. Wie lässt sich dann Anonymität bewahren? Ein Ansatz ist Verlass auf missbrauchsichere Hardware, um Ausgebende zu zwingen, sich „ehrlich" zu benehmen und nicht doppelt auszugeben) (siehe, beispielsweise, S. Even, O. Goldreich und Y. Yacobi, Electronic Wallet, Proc. CRYPTO '83, Plenum Press (1984), PP. 383–386). Auf dieser Prämisse beruhende Programme sind aber äußerst "empfindlich". Wenn sich jemand erfolgreich an der Hardware zu schaffen gemacht hat, dann ist diese Person nicht nur der Doppelausgabe fähig, sondern jeder, irgendwo, der sich die in der Hardware enthaltenen Informationen beschafft (vielleicht, z. B. kauft), kann willkürlich hohe Beträge nach Belieben ausgeben. Heutige Technologie in Bezug auf Missbrauchsicherheit ist weit davon entfernt, ausreichend verlässlich zu sein, dass man ihr trauen kann, solch ein enormes Risiko zu vereiteln.
Ein weiterer Ansatz ist kryptografisch. Beispielsweise ist es unter gewissen sehr starken kryptografischen Voraussetzungen möglich, Protokolle zu konstruieren, die „blinde" Geld-Informationen erstellen, die später als gültiges Geld erkannt, aber nicht mit irgendeinem besonderen Ablauf des Protokolls in Verbindung gebracht werden können. (Siehe, beispielsweise, D. Chaum, Privacy Protected Payments-Unconditional Payer and/or Payee untraceability, SMART CARD 2000: The future of IC Cards-Proc. IFIP WG 11.6 Intl Conf., North-Holland (1989). pp. 69–93; und D. Chaum, Online Cash Checks Proc. Eurocrypt '89, Springer-Verlag (1989), pp. 288–293.
US 4,914,698 beschreibt ein kryptografisches System und ein digitales Unterschriftssystem mit öffentlichem Schlüssel, das „Unverknüpfbarkeit" bereitstellt. Ein Objekt der US 4,914,698 ist, ein digitales Unterschriftssystem mit Schlüssel bereitzustellen, das es einer ersten Partei ermöglicht, Unterschriften an eine zweite Partei auszustellen, und das es der zweiten Partei erlaubt sie einer dritten Partei bereitzustellen, wobei Kooperation der ersten und dritten Partei nicht in der Lage ist, zweite Parteien zurückzuverfolgen und jede Unterschrift nicht mehr als einmal gezeigt wird. Die Offenbarung der US 4,914,698 verlässt sich auf ein „blindes Unterschriftssystem" und um eine Blindsicherheit zu erzielen, ist intensive patenverarbeitung erforderlich.
Die US 4,937,593 bezieht sich ebenso auf ein „blindes" elektronisches Geldsystem, und sowohl die US 4,914,698 als auch die US 4,987,593 erfordern blinden Transfer zwischen einer Partei und einer Bank, zusammen mit mehrfachen Verifizierungsschritten, um zu überprüfen, dass Transfers erfolgreich und sicher gewesen sind.
Zusammenfassung der Erfindung
Wir stellen ein einfaches, praktisches, elektronisches Online-Geldsystem beruhend auf der Annahme eines Netzes vor, in dem anonyme Kommunikation ohne Ursprungserkennung möglich ist. Im Allgemeinen verwendet die Erfindung zwei einfache graphische Grundformen, nämlich eine Einwegfunktion und ein Unterschriftsprogramm. Beide sind auf dem Fachgebiet gut bekannt und Beschreibungen sind in der öffentlich verfügbaren Literatur über Kryptographie, z. B. Applied Cryptoaraphy, Bruce Schneier, John Wiley & Sons, Inc. (1994) zu finden. Das System schützt die Anonymität der Ausgebenden und garantiert außerdem die Validität ihrer elektronischen Münzen, und die verwendeten Münzen sind unvergesslich und können nicht mehr als einmal ausgegeben werden.
Im Allgemeinen umfasst die Erfindung, in einem Aspekt, ein elektronisches Geldsystemprotokoll für sichere Transaktionen ohne Ursprungserkennung, gekennzeichnet durch:
Verwendung einer öffentlich zu offenbarenden Einwegfunktion f₁(x), um ein Bild f₁(x₁) ab einem Urbild x₁ zu generieren; Senden des Bilds f₁(x₁) in einer nicht blinden Form an eine zweite Partei (30); Empfangen ab der zweiten Partei (30) eines öffentlich zu offenbarenden Vermerks einschließlich einer digitalen Unterschrift, wobei besagter öffentlich zu offenbarender Vermerk eine Verpflichtung seitens der zweiten Partei (30) repräsentiert, einem ersten Vorleger besagten Urbilds x₁ an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren. Der empfangene, unterzeichnete Vermerk repräsentiert eine Verpflichtung seitens der zweiten Partei, einem ersten Vorleger des Urbilds x₁ an die zweite Partei einen vorbestimmten Geldbetrag zu kreditieren.
Bevorzugte Ausführungsbeispiele schließen folgendes Merkmal ein. Das elektronische Geldsystemprotokoll schließt außerdem das Senden des Urbilds x₁ an eine dritte Partei als Zahlung für den Kauf von Gütern oder Dienstleistungen von der dritten Partei ein.
Als andere Möglichkeit schließt es weiter ein:
Selektieren eines zweiten Urbilds x₂;
Verwendung einer zweiten öffentlich zu offenbarenden Einwegfunktion f₂(x), um ein zweites Bild f₂(x₂) ab dem zweiten Urbild x₂ zu generieren;
Senden des ersten Urbilds x₁ und der nicht blinden Form des zweiten Bilds f₂ (x₂) an die zweite Partei (30); und
Empfangen ab der zweiten Partei (3d) eines zweiten öffentlich zu offenbarenden Vermerks, einschließlich einer digitalen Unterschrift, wobei besagter zweite öffentlich zu offenbarende Vermerk eine Verpflichtung durch die zweite Partei (30) repräsentiert, einem ersten Vorleger besagten zweiten Urbilds x₂ an die zweite Partei (3d) einen vorbestimmten Geldbetrag zu kreditieren. In beiden Fällen sind f₁(x) und f₂(x) dieselbe Funktion. Im letzteren Fall geschieht das Senden des ersten Urbilds x₁ und der nicht blinden Form des zweiten Bilds f₂(x₂) an die zweite Partei anonym und die zweite Partei ist eine Bank.
Außerdem schließt das Protokoll in bevorzugten Ausführungsbeispielen die Schritte Verkettung eines Unterschriftsschlüssels einer dritten Partei mit dem ersten Urbild x₁, um einen Informationsblock zu bilden; der Verschlüsselung des Informationsblocks durch Verwendung eines Verschlüsselungsschlüssels der zweiten Partei, um einen verschlüsselten Informationsblock zu generieren; und Senden des verschlüsselten Informationsblocks an die dritte Partei ein.
Im Allgemeinen ist die Erfindung, in einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen eines ersten Urbilds x₁ ab einer ersten Partei, worin das Urbild x₁ ein erstes Bild f₁(x₁) produziert, wenn es durch eine erste Einwegfunktion f₁(x) verarbeitet wird und wobei mit besagtem ersten Urbild x₁ eine Verpflichtung seitens einer zweiten Partei assoziiert ist, einem ersten Vorleger des besagten ersten Urbilds x₁ einen vorbestimmten Geldbetrag zu kreditieren; Selektieren eines zweiten Urbilds x₂; Verwendung einer zweiten Einwegfunktion f₂(x), um ein zweites Bild f₂(x₂) ab dem zweiten Urbild x₂ zu generieren; Senden des ersten Urbilds x₁ und einer nicht blinden Form des zweiten Bilds f₂(x₂) an die zweite Partei; und Empfangen eines Vermerks, einschließlich einer digitalen Unterschrift ab der zweiten Partei, einschließt, worin der Vermerk eine Verpflichtung seitens der zweiten Partei repräsentiert, einem ersten Vorleger des zweiten Urbilds x₂ an die zweite Partei einen vorbestimmten Geldbetrag zu kreditieren.
Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen eines verschlüsselten Informationsblocks ab einer ersten Partei, wobei man den Block verschlüsselter Information generierte, indem zuerst ein öffentlicher Unterschriftsschlüssel einer zweiten Partei mit einem ersten Urbild x₁ verkettet wurde, um einen Informationsblock zu bilden und der Infonnationsblock dann durch Verwendung eines Verschlüsselungsschlüssels einer dritten Partei verschlüsselt wurde; Selektieren eines zweiten Urbilds x₂; Verwendung einer zweiten Einwegfunktion f₂(x) zum Generieren eines Bilds f(x₂) ab dem Urbild x₂; Formen einer Mitteilung einschließlich des verschlüsselten Informationsblocks zusammen mit dem Bild f(x₂) in einer nicht blinden Form; Senden der Mitteilung an die dritte Partei; und Empfangen ab der dritten Partei eines unterzeichneten Vermerks, einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung durch die dritte Partei repräsentiert einem ersten Vorleger des Urbilds x₂ einen vorbestimmten Geldbetrag zu kreditieren, einschließt.
Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Empfangen ab einer ersten Entität einer nicht blinden Form eines Bilds f₁(x₁), das durch Anwendung einer Einwegfunktion f₁(x) auf ein Urbild x₁ generiert wurde; Generieren einer Mitteilung, die eine Verpflichtung enthält, einer vorbestimmten Betrag an einen ersten Vorleger des Urbilds x₁ zu kreditieren; Unterschreiben der Mitteilung mit einer digitalen Unterschrift; und Senden der Mitteilung zusammen mit der digitalen Unterschrift an die erste Partei einschließt.
In bevorzugten Ausführungsbeispielen schließt das elektronische Geldsystemprotokoll außerdem anschließendes Empfangen des Urbilds x₁ ab einer dritten Partei; Überprüfen einer Datenbank auf das Urbild x₁; falls das Urbild x₁ nicht in der Datenbank gefunden wird, Kreditieren der dritten Partei mit dem vorbestimmten Geldbetrag; und Hinzufügen des Urbilds x₁ zur Datenbank ein. Als andere Möglichkeit schließt das Protokoll anschließendes Empfangen des Urbilds x₁ und eines nicht blinden Bilds f₂(x₂) ab einer dritten Partei, worin das nicht blinde Bild f₂(x₂) durch Anwendung einer Einwegfunktion f₂(x) auf ein Urbild x₂ generiert wurde; Überprüfen einer Datenbank auf das Urbild x₁; falls das Urbild x₁ nicht in der Datenbank aufgefunden wird, Generieren eines unterzeichneten Vermerks, einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung representiert, einen vorbestimmten Geldbetrag an einen ersten Vorleger des Urbilds x₂ zu kreditieren; und Hinzufügen des Urbilds x₁ zur Datenbank ein.
Ebenso in bevorzugten Ausführungsbeispielen kennzeichnet die Erfindung das Empfangen einer Mitteilung ab einer zweiten Partei, worin die Mitteilung durch Verketten eines Verschlüsselungsschlüssels einer dritten Partei mit einem ersten Urbild x₁ generiert wurde, um einen Informationsblock, durch Verschlüsseln des Informationsblocks mit einem ersten Verschlüsselungsschlüssel, zu bilden, um einen verschlüsselten ersten Block zu generieren, und durch Verketten eines nicht blinden Bilds f₂(x₂) mit dem verschlüsselten ersten Informationsblock, worin das nicht blinde Bild f₂(x₂) durch Verwendung einer Einwegfunktion f₂(x) generiert wurde, um ein Bild f₂(x₂) ab einem Urbild x₂ zu generieren. Es kennzeichnet sie weiter das Entschlüsseln des verschlüsselten ersten Informationsblocks; Generieren eines Vermerks einschließlich einer digitalen Unterschrift, worin der Vermerk eine Verpflichtung repräsentiert, einem ersten Vorleger des Urbilds x₂ einen vorbestimmten Geldbetrag zu kreditieren; und Schicken des Vermerks an die zweite Partei.
Im Allgemeinen ist die Erfindung, in noch einem weiteren Aspekt, ein elektronisches Geldsystemprotokoll, das die Schritte Senden eines nicht blinden Bilds f₂(x₂) an eine zweite Partei, worin das nicht blinde Bild f₂(x₂) durch Anwendung einer Einwegfunktion f₂(x) auf ein Urbild x₂ generiert wurde; Empfangen eines unterschriebenen Vermerks ab der zweiten Partei, worin der nicht blinde Vermerk eine digitale Unterschrift einschließt und eine Verpflichtung repräsentiert, einem ersten Vorleger des Urbilds x₂ einen vorbestimmten Geldbetrag zu kreditieren; und als Antwort auf den Empfang des nicht blinden Vermerks ab der zweiten Partei, Autorisieren der Lieferung von Gütern und/oder Dienstleistungen an eine dritte Partei einschließt.
Die Erfindung bietet eine einfache, billige Art und Weise bargeldartige Transaktionen zu tätigen, wobei der Austauschgegenstand (d. h. die abgehobene Münze) die Eigenschaften tatsächlichen Bargelds hat. Beispielsweise ist er: (1) mehr oder weniger anonym; (2) sicher; (3) billig zu verwenden; und (4) leicht herumzutragen und auszutauschen.
Parteien sind durch die Tatsache, dass sie den Wert x₁ für eine spezielle Münze geheim halten, bis sie ausgegeben ist, dagegen geschützt, dass eine unehrliche Bank abgehobene Münzen nicht einlöst, So lang wie eine spezielle Münze f(x₁) öffentlich und nicht anonym deponiert wird, kann von der Bank verlangt werden, dass sie diese einlöst, außer sie kann die zugehörige x₁ liefern. Natürlich kann die Bank eine anonym ausgetauschte Münze f(x₁), während des eigentlichen Austausches, nicht einlösen, indem sie nach Empfangen von x₁ behauptet, dass die Münze bereits ausgegeben worden ist. Jedoch kann die Bank unmöglich wissen, wer durch solch einen „Zeche prellenden" Trick betrogen wird, und sie ist daher anfällig für Überwachung und öffentliche Bloßstellung.
Abschließend sei gesagt, dass die Banken selbst durch die Sicherheit des digitalen Unterschriftsprogramms, das zum Unterzeichnen elektronsicher Münzen eingesetzt wird, gegen Fälschung geschützt sind. Überdies sind sie gegen „Doppelausgabe" (oder "Doppeleinzahlung") durch ihre Fähigkeit geschützt, x₁-Werte für Münzen ewig zu speichern.
Andere Vorteile und Merkmale werden an Hand der folgenden Beschreibung des bevorzugten Ausführungsbeispiels und der Ansprüche offenkundig.
Kurzbeschreibung der Zeichnungen
1 ist ein Diagramm eines nicht anonymen Abhebungsprotokolls;
2 ist ein Diagramm eines anonymen Austauschprotokolls;
3 ist ein Diagramm eines anonymen Kaufprotokolls;
4 ist ein Diagramm eines nicht anonymen Einzahlungsprotokolls;
5 ist ein Diagramm eines anonymen alternativen Zahlungsprotokolls;
6 ist ein Diagramm eines Protokolls für eine anonyme oder nicht anonyme „Hinterlegungszahlung" oder Zahlungsanweisung; und
7 ist ein Diagramm eines verschlüsselten Protokolls für eine Zahlungsanweisung.
Beschreibung der bevorzugten Ausführungsbeispiele
Die Fähigkeit anonym zu kommunizieren ist in gewissem Sinne a priori notwendig, wenn anonyme Geldtransaktionen stattfinden sollen, da Informationen über Kommunikationen einer Partei offensichtlich Informationen über die Geschäftstätigkeiten der Partei offenbaren werden. In der Praxis könnte die Anonymität der Kommunikation vielleicht auf nicht mehr als der Zuversicht beruhen, dass die Telefongesellschaft die Vertraulichkeit ihres Systems schützt. Oder aber vertrauen Parteien vielleicht in einen oder mehrere „anonyme Weiterversender", um ihre Identitäten zu verschleiern, oder verlassen sich auf die Durchführung einer der anderen Techniken aus der öffentlich verfügbaren Literatur.
Angenommen, dass nicht nur Kommunikationen zwischen Parteien in Bezug auf dritte Parteien anonym sind, sondern ebenso, dass die kommunizierenden Parteien einander anonym sind. (Bei typischen Durchführungen ist die letztere Kondition, Selbstidentifizierung ausgenommen, eine natürliche Folge der Ersteren). Ein einfaches, irgendwie anonymes elektronisches Geldsystemprotokoll in solch einer Umgebung ist in 1 gezeigt.
In den folgenden Beschreibungen verschiedener Protokolle (siehe 1–7), nehmen wir generell auf drei Parteien Bezug, nämlich einen Kunden 10, einen Verkäufer 20 und eine Bank 34. Der Kunde 10 ist natürlich generell repräsentativ für den Zahler und der Verkäufer 20 ist generell repräsentativ für den Zahlungsempfänger. Es versteht sich aber, dass diese Bezeichnungen für den Zweck der Klarheit gewählt wurden und, dass sie nicht den Umfang der Erfindung begrenzen sollen. Es wäre ebenso gültig, wenn man sie als Partei A, Partei B und Partei C bezeichnen würde.
In den Abbildungen sind die verschiedenen Entitäten durch Blöcke repräsentiert und die Informationsübertragungen von einer Entität zu einer anderen sind durch Linien angezeigt, die die entsprechenden Blöcke verbinden. Jede Linie repräsentiert eine Übertragung gewisser Informationen von einer Entität zu einer anderen in der durch einen Pfeil am Ende der Linie angezeigten Richtung. Die Informationen, die übertragen werden, sind unter den Linien symbolisch zusammengefasst.
Obwohl jeder Block etikettiert ist und unten als eine spezielle Entität repräsentierend beschrieben wird, kann er durch ein Rechengerät implementiert werden, das die Berechnungen und die Kommunikationen verrichtet, die von jener Entität ausgeführt werden. Bei den Rechengeräten könnte es sich um eine breite Palette elektronischer Geräte handeln, die beispielsweise einen Personalcomputer, eine PCMCIA-Karte, ein PDI (Personaldatenaustauschgerät), eine Chipkarte, einen Handcomputer oder eine leistungsfähigere Workstation einschließen, um nur einige zu nennen. Die Bankseite der Protokolle, die nachfolgend beschrieben sind, lässt sich von einem Server durchführen, der programmiert ist, elektronische Transaktionen zu handhaben, die jenen ähneln, die gegenwärtig Transaktionen von SB-Bankautomaten handhaben. Der Server würde mehrere einlaufende Telefonleitungen aufweisen und eine Datenspeichermöglichkeit zum Speichern der relevanten Daten einschließen.
Natürlich sollte ebenso verstanden werden, dass die Rechengeräte, entweder intern oder extern, alle Speicherkapazität einschließen, die für die Daten und Programme erforderlich ist, die mit der Durchführung der Protokolle zu tun haben. Überdies schließen sie Geräte (z. B. ein Modem) ein, die ihnen ermöglichen, mit anderen Rechengeräten zu kommunizieren. Außerdem können die Kommunikationsmedien, über die die Informationsübertragungen stattfinden, ebenso irgendwelche einer großen Zahl von Möglichkeiten sein, die beispielsweise Telefonleitungen, Kabel, das Internet, Satellitenübertragungen oder Funkübertragungen einschließen. Anders ausgedrückt ist nicht beabsichtigt, dass die Erfindung entweder hinsichtlich der verwendeten Gerätearten oder der eingesetzten Kommunikationsverfahren eingeschränkt wird. Den Möglichkeiten und Kombinationen werden nur durch die eigene Phantasie Grenzen gesetzt.
Für die folgenden Protokolle wird angenommen, dass die Bank 30 eine Einwegfunktion f(x) auswählt und öffentlich verfügbar macht. Oder aber könnte solch eine Funktion durch eine beliebige Partei öffentlich verfügbar gemacht werden, so lang alle Parteien der Transaktionen Zugriff darauf haben und sie benutzen können. Generell meinen wir mit einer Einwegfunktion eine Funktion f(x), so dass f(x₁) durch Verwenden von x₁ produziert wird und, wenn f(x₁) gegeben ist, man x₁ nicht bestimmen kann. In der folgenden Beschreibung wird auf x₁ auch als ein Urbild von f(x₁) und auf f(x₁) als ein Bild von x₁ Bezug genommen.
Es könnte sein, dass perfekte Einwegfunktionen in der Praxis eigentlich nicht existieren. Das heißt, dass für alle Funktionen, von denen man jetzt glaubt, dass sie Einwegfunktionen sind, eines Tages genügend Rechenkraft oder Techniken vorliegen können, um x₁ zu bestimmen, wenn f(x₁) gegeben ist. Daher beabsichtigen wir mit dem Begriff Einwegfunktion auch jene Funktionen einzuschließen, für die es sehr schwer, aber nicht notwendigerweise unmöglich ist, x₁ zu berechnen, wenn f(x₁) bekannt ist.
Die Einwegfunktion kann eine einer Reihe von gebräuchlichen Hash-Funktionen (z. B. MD5, SHA usw.) sein. Außerdem könnte es man mehrere Einwegfunktionen verwenden und verketten. Auf dem Fachgebiet sind eine Menge Einwegfunktionen bekannt und typisch lassen sich viele davon leicht berechnen und daher auf einer Chipkarte implementieren.
Anhand dieses Hintergrunds werden jetzt die verschiedenen Protokolle, die die Erfindung verkörpern, beginnend mit einem Abhebungsprotokoll beschrieben, bei dem sich ein Kunde „Bargeld" von der Bank beschafft.
Abhebungsprotokoll
Eine Abhebung wird auf die in 1 gezeigte Weise durchgeführt. Der Kunde 10 wählt eine beliebige Zahl x₁ und verwendet f(x), um ein Bild von x₁ zu generieren. Der Wert x₁ ist eine von einem Zufallsgenerator erhaltene zufällige Zahlenkette, auf die vielleicht optional einige Nachverarbeitung angewandt werden kann. Sie könnte beispielsweise 128 Bits lang sein. Kunde 10 hält sie geheim, bis eine Zahlung stattfindet und dann wird sie als die Zahlung gesendet.
Der Kunde 10 hebt dann eine Münze (nicht anonym) von der Bank 30 ab, indem er jene Bank 30 ersucht, einen Geldwert mit f(x₁) zu assoziieren. Die Bank 30 entspricht, indem sie digital eine Erklärung dahingehend unterschreibt, somit f(x₁) als eine gültige Münze „zertifiziert" und ein Konto, das der Kunde 10 bei der Bank 30 unterhält, um den Betrag des Werts der Münze belastet. Anders ausgedrückt, gibt die Bank 30 eine Erklärung oder eine Angabe heraus, die im Effekt anzeigt, dass „Dem ersten Vorleger des Urbilds von f(x₁) ein Betrag Z kreditiert wird" und danach unterzeichnet oder zertifiziert die Bank 30 dann jene Erklärung.
Techniken für das Unterzeichnen oder Zertifizieren von Informationen (z. B. durch Verwendung eines Paars privater-öffentlicher Schlüssel) und die Verwendung digitaler Unterschriften sind auf dem Fachgebiet gut bekannt. Für weitere Einzelheiten beziehen Sie sich bitte auf die weit anerkannten Referenzen auf dem Gebiet, z. B. Angewandte Kryptographie von Bruce Schneier, John Wiley & Sons, Inc., (1994).
Im Allgemeinen ist ein Unterschriftsprogramm eine Art und Weise ein Skript zu etikettieren. Typischerweise verwendet es ein Paar öffentlicher privater Schlüssel. Öffentliche-private Schlüssel lassen sich durch Einwegfunktionen implementieren, obwohl ein praktischerer Ansatz darin besteht, eine Falltürfunktion zu verwenden, die die Tendenz hat, effizienter zu sein (z. B. siehe von Schneier beschriebene RSA, DSS, EIGamal Algorithmen). Der private Schlüssel wird verwendet, um das Skript oder einen Hash des Skripts zu verschlüsseln, um eine digitale Unterschrift zu produzieren, die dann an das Skript angehängt wird. Die digitale Unterschrift repräsentiert eine Unterschrift der Entität, der der private Schlüssel gehört, da keine andere Entität solch eine Unterschrift ab jenem Skript generieren kann. Wenn eine zweite Entität das Etikett mittels des öffentlichen Schlüssels entschlüsseln kann, weiß sie, dass die Unterschrift von der Entität generiert wurde, der der private Schlüssel gehört.
Damit Zertifizierung funktioniert, wird offensichtlich angenommen, dass jeder den öffentlichen Schlüssel der Unterzeichnerbehörde hat und diesem vertraut und Zuversicht hat, dass der private Schlüssel nicht kompromittiert worden ist.
Durch das Veröffentlichen ihres öffentlichen Schlüssels und das Anhängen digitaler Unterschriften an eine Erklärung, dass die Bank 30 eine spezifizierte Summe an die Entität zahlt, die zuerst ein Urbild von f(x₁) präsentiert, verknüpft sich die Bank 30 eindeutig mit ihrer Verpflichtung und schützt sich gegen mögliche Fälscher.
Die von der Bank generierte, zertifizierte Erklärung wird hierin als C(f(x₁)) designiert, und hierin ebenso als ein Vermerk bezeichnet. Dieser Vermerk wird dem Kunden 10 zurückgegeben. Außerdem kann er öffentlich verfügbar gemacht werden, da er keinen Wert für jemanden hat, der x₁ nicht kennt.
Austauschprotokoll
Eine Partei (z. B. Kunde 10 oder Verkäufer 20) kann jederzeit anonym eine Münze bei der Bank 30 „austauschen". In der Tat, ist es wichtig dies sofort nach Empfang einer Münze ab einer anderen Partei zu tun, um das Risiko zu minimieren, dass jemand anders der Bank 30 x₁ vor dem echten Empfänger der Münze liefern wird. Eine unehrliche Partei könnte versuchen, die Münze mehrmals zu senden, indem sie x₁ mehreren Parteien gibt. Wenn das geschieht, wird der erste Empfänger, der die Bank 30 erreicht, ihren Wert erhalten und alle anderen Empfänger der Münze werden sie nicht gegen eine andere Münze umtauschen können. Für den Verkäufer 20 ist der Zeitpunkt des Austausches weniger kritisch, weil der Verkäufer 20 vermutlich nicht die Güter oder Dienstleistungen liefern wird, die gekauft werden, bis ihm versichert wurde, dass die erhaltene Münze immer noch gültig ist.
Mit Bezug auf 2 und unter der Annahme, dass der Kunde 10 eine Münze anonym austauschen möchte, werden x₁ und ein weiteres Bild der Funktion, f(x₂) für ein zufällig gewähltes x₂ vom Kunden 10 an die Bank 30 geliefert. Anders ausgedrückt versucht der Kunde 10 eine wie vorher beschriebene Abhebung vorzunehmen, liefert aber gleichzeitig den abzuhebenden Betrag wie er von x₁ repräsentiert wird. Die Bank 30 zertifiziert einfach f(x₂) und hält x₁ in einer Datenbank 40 als Nachweis, dass f(x₁) bereits „ausgegeben" worden ist. Es ist eigentlich diese Interaktion, die doppeltes Ausgeben von x1 verhindert.
Da sich f(x₁) und C(f(x₁)) bereits im Besitz der Bank 30 befinden, ist das Senden jener Information an die Bank 30 zusammen mit x₁ und f(x₂) optional.
Wenn der bankseitige Teil des Protokolls auf einem Server durchgeführt wird, speichert er automatisch die empfangenen x_i. Und jedes Mal, wenn die Bank 30 ein weiteres x_j empfängt, prüft sie es zuerst gegen die x_i, die bereits kassiert (d. h., empfangen) worden sind.
Man kann eine Reihe von Austauschtransaktionen verwenden, um zu verschleiern, wer eigentlich die Münze ausgibt. Beachten Sie, dass bei einer Austauschtransaktion nur f(x₂) nicht aber der Besitzer von x₂ offenbart werden braucht. Im Gegensatz zu alternativen Ansätzen, Anonymität zu erzielen, ist das Blindmachen der Münze nicht erforderlich. Tatsächlich ist es wünschenswert, dass f(x₁) nicht blind gemacht wird, sondern öffentlich bekannt gemacht wird.
Was immer die Schritte sind, die man vornehmen möchte, um die Anonymität von Kommunikation zu sichern, sind diese ausreichend die Anonymität der Transaktion zu sichern (d. h., Erzielen von Anonymität ist möglich aber auch optional).
Dieses Verfahren lässt sich auch dafür verwenden, Wechselgeld für eine Münze eines gegebenen Werts herauszugeben. Anstatt f(x₂) zu senden, kann die das Wechselgeld suchende Partei mehrfache f(x), z. B. f(x₂), f(x₃), f(x₄), jede für einen speziellen Wert, senden, deren Summe dem mit f(x₁) assoziierten Wert entspricht. Die Bank sendet mehrere unterzeichnete Vermerke, C(f(x_i), zurück.
Kaufprotokoll
Bezugnehmend auf 3, verwendet das tatsächliche Ausgeben von Münzen ein Protokoll, das dem Austauschprotokoll ähnlich ist. Die ausgebende Partei (z. B. Kunde 10) leitet x₁ an die empfangende Partei (z. B. Verkäufer 20) weiter. Da es wahrscheinlich ist, dass der Verkäufer 20 keinen direkten und unmittelbaren Zugriff auf f(x₁) und C(f(x₁)) hat, schließt der Kunde 10 auch diese Informationen als Teil der Transaktion ein. Der Verkäufer 20 ruft dann sofort die Bank 30 an und tauscht x₁ gegen eine „frische" Münze aus, unter der Annahme, dass die Bank 30 zuerst verifiziert, dass sie nicht vorher ausgegeben worden ist. Der Verkäufer 20 verwendet das in 2 dargestellte Austauschprotokoll, um diesen Austausch durchzuführen. Angenommen, dass der Austausch erfolgreich war, liefert der Verkäufer 20 dann die gekauften Güter und/oder Dienstleistungen an den Kunden 10.
Einzahlungsprotokoll
Bezugnehmend auf 4 können auch Münzen jederzeit nicht anonym bei der Bank 30 eingezahlt werden. Wenn der Verkäufer 20, beispielsweise, eine Münze f(x₁) einzahlen möchte, die er nicht ausgegeben hat, sendet er x₁, zusammen mit einer Einzahlungsaufforderung, an die Bank 30. Der Verkäufer 20 kann auch optional f(x₁) sowie den Vermerk C(f(x₁)) senden.
Nach Erhalt von x₁ und der Einzahlungsaufforderung prüft die Bank 30 ihre Datenbank, um zu bestimmen ob x₁ bereits der Bank vorgelegt worden ist. Natürlich, wenn sie bereits vorgelegt worden ist, wird die Bank 30 das Konto des Verkäufers nicht kreditieren und dem Verkäufer 20 mitteilen, dass es keine gültige Münze ist. Wenn die Bank 30 x₁ nicht bereits erhalten hat, kreditiert sie das Konto des Verkäufers mit dem entsprechenden Betrag und sendet dem Verkäufer 20 eine Einzahlungsquittung, die bestätigt, dass eine Gutschrift eingetragen worden ist.
Erweiterungen der Protokolle
Die Austausch- und Zahlungsprotokolle in dem oben beschriebenen elektronischen Geldprogramm erlauben eine Reihe von Variationen, die den verfügbaren Kommunikationsmitteln und den gewünschten Anonymitätsebenen angepasst werden können. Wenn der Kunde 10, beispielsweise mit Bezug auf 5, leichteren Zugriff auf die Bank 30 als der Verkäufer 20 hat, dann kann der Verkäufer 20 zuerst ein f(x₂) an den Kunden 10 liefern, der dann das Austauschprotokoll für den Verkäufer 20 durchführt und die unterzeichnete Münze, d. h. C(f(x₂)), als Nachweis der Zahlung zurücksendet. Das Austauschprotokoll lässt sich, wie bereits erwähnt, anonym durchführen.
Oder aber, wenn sowohl der Kunde 10 als auch der Verkäufer 20 besseren Kommunikationszugriff auf die Bank 30 als aufeinander haben, dann können die Parteien ein Protokoll für eine „Hinterlegungszahlung", wie es in 6 dargestellt ist, verwenden. In Übereinstimmung mit diesem Protokoll, liefert der Kunde 70 die Zahlung bei der Bank 30 für den Verkäufer 20 ab und der Verkäufer 20 holt sich anschließend die Zahlung von der Bank 30 ab.
Die Schritte des Protokolls für eine „Hinterlegungszahlung" sind wie folgt. Zunächst liefert der Kunde 10 ein x₂ für eine gültige Münze eines spezifischen Betrags, zusammen mit einem öffentlichen Unterschriftsschlüssel p des Verkäufers 20, und andere Informationen bezüglich der Transaktion an die Bank 30. Zum Beispiel möchte der Kunde 10 vielleicht, unter den anderen Informationen, die zu kaufenden Güter identifizieren, die Transaktion und/oder den Verkäufer identifizieren, und die deklarierten Absichten des Kunden hinsichtlich Zahlung anzeigen, wobei das Bargeld in eine Art „elektronische Zahlungsanweisung" verwandelt wird. Optional kann der Kunde 10 auch f(x₁) und den Vermerk C(f(x₁)) senden. Da aber, wie vorher erwähnt, diese Informationen der Bank 30 bereits bekannt sind, könnte sich dies als nicht notwendig erweisen.
Beachten Sie, dass eine Aufzeichnung, die vielleicht anhand der vom Kunden 10 gelieferten anderen Informationen zusammengestellt wird, bei Fernzahlungseinstellungen von besonderen Nutzen sein kann, wo die Natur der Transaktion anderweitig in der Zahlungshandlung selbst nicht implizit enthalten ist, wie es typischerweise bei Zahlungen der Fall ist, die persönlich geleistet werden.
Wenn der Verkäufer 20 nicht anonym bleiben möchte, könnte der öffentliche Unterschriftsschlüssel öffentlich mit der Identität des Verkäufers 20 assoziiert werden; oder, wenn Anonymität gewünscht wird, kann der öffentliche Unterschriftsschlüssel ein zweckgebundener öffentlicher Unterschriftsschlüssel ohne assoziierte Identität sein. Im letzteren Fall wird der öffentliche Schlüssel vertraulich an getreue Bekannte weitergegeben oder einfach unter einem Pseudonym veröffentlicht,
Die Bank 30 erklärt sich einverstanden, den mit x₁ assoziierten Betrag der ersten Münze f(x₁) zuzuordnen, die ihr vorgelegt wird, die auch mit dem privaten Unterschriftsschlüssel unterschrieben wird, der dem vorher gelieferten öffentlichen Unterschriftsschlüssel p entspricht. Daher braucht der Verkäufer 20, um die Zahlung für die Güter zu erhalten, die der Käufer 10 kaufen möchte, nur einfach eine Abhebung von der Bank 30, unter Verwendung des in Verbindung mit 1 beschriebenen Protokolls, zu tätigen. Das heißt der Verkäufer 20 wählt zufällig ein x₂ und verwendet f(x), um das entsprechende Bild f(x₂) zu generieren. In diesem Fall unterschreibt der Verkäufer 20 aber f(x₂) mit seinem privaten Unterschriftsschlüssel, bevor er f(x₂) an die Bank 30 sendet. Außerdem geschieht in diesem Fall die Abhebung nicht vom Konto des Verkäufers, sondern ist einfach ein Transfer des vorher vom Kunden 10 gelieferten Betrags.
Die Bank 30 verwendet den öffentlichen Unterschriftsschlüssel des Verkäufers, um zu verifizieren, dass f(x₂) vom Verkäufer 20 unterschrieben ist (d. h., von der Partei an die der Geldtransfer zu tätigen ist). Nach Bestätigen der Unterschrift auf f(x₂), stellt die Bank 30 einen Vermerk C(f(x₂)) aus, den sie dem Verkäufer 20 sendet.
Nachdem der Verkäufer 20 den Vermerk C(f(x₂)) erhält, der bestätigt, dass das Geld eingegangen ist, sendet der Verkäufer 20 die Güter an den Kunden 10.
Natürlich könnte die Bank 30 theoretisch betrügen, indem sie einfach das Geld behält, anstatt es dem Zahlungsempfänger zuzuordnen. Um die Bank 30 ehrlich zu halten, verlassen wir uns jedoch auf die Anonymität des Zahlenden oder wenigstens auf die Möglichkeit, dass der Zahlende die Transaktion der öffentlichen Aufsichtsbehörde offenbaren könnte.
In einer Umgebung, in der Kommunikationen unter den Parteien vielleicht abgefangen werden können, gibt es eine Reihe Wege, die Austauschprotokolle und speziell den darin weitergeleiteten geheimen x-Wert vor Lauschern zu sichern. Das natürlichste Verfahren ist die Verschlüsselung des öffentlichen Schlüssels. Wenn Parteien ihre gegenseitigen öffentlichen Verschlüsselungsschlüssel sowie die Banken kennen, dann können alle der obigen Protokolle gleich gut in der durch Lauscher gefährdeten Umgebung funktionieren, so lang jede Mitteilung, außer die von der Bank 30 gesendeten Mitteilungen, mit dem öffentlichen Verschlüsselungsschlüssel des Empfängers verschlüsselt wird oder mit einem symmetrischen "Sitzungsschlüssel", der den öffentlichen Verschlüsselungsschlüssel des Empfängers benutzt, verschlüsselt wird. Die Mitteilungen der Bank können natürlich als nicht vertraulich erachtet werden, da sie nur aus unterschriebenen Münzen der Form f(x_i) bestehen, wobei x_i von jemand anders geheim gehalten wird. Die Verwendung von Mitteilungs-Authentizierungsscodes, bzw. MAC's, mit jeder Verschlüsselung macht es außerdem möglich sicherzustellen, dass sich niemand, außer dem Versender, an der Mitteilung zu schaffen macht, bevor sie an ihrem Bestimmungsort eintrifft.
Die Verwendung von Verschlüsselung mit einem öffentlichen Schlüssel (Public-Key-Verschlüsselung) ermöglicht außerdem eine andere Art "elektronische Zahlungsanweisung". In diesem Fall, der in 7 dargestellt ist und auf den generell als ein verschlüsseltes Protokoll für eine Zahlungsanweisung Bezug genommen wird, verschlüsselt der Kunde 10 den geheimen x₁-Wert für irgendeine gültige elektronische Münze, zusammen mit dem öffentlichen Schlüssel p des Verkäufers 20 und jeder anderen gewünschten Identitäts- oder Transaktionsinformation, wie beim vorhergehenden Protokoll für eine „Hinterlegungszahlung". Der Kunde 10 verschlüsselt diese Informationen mit dem öffentlichen Verschlüsselungsschlüssel der Bank oder mit einem Sitzungsschlüssel, der dann mit Hilfe des öffentlichen Verschlüsselungsschlüssels der Bank verschlüsselt wird. Der Kunde 10 sendet dann die verschlüsselten Daten direkt an den Verkäufer 20.
Um sie "einzulösen", wählt der Verkäufer 20 einen Zufallswert x₂, generiert sein Bild f(x₂) und hängt f(x₂) an die Mitteilung E an, die er vom Kunden 10 erhielt. Wie zuvor ist f(x₂) von der Bank zu unterschreiben, so dass es den Transfer von Geld an den Verkäufer 20 repräsentieren wird. Der Verkäufer 20 unterzeichnet die komplette Mitteilung (oder wenigstens f(x₂)) mit dem privaten Unterschriftsschlüssel, der mit der öffentlichen Unterschrift p assoziiert ist, und leitet E, f(x₂) und die Unterschrift an die Bank 30 weiter. Optional könnte der Verkäufer 20 diese Mitteilung auf die zuvor beschriebene Weise weiter verschlüsseln, d. h. mit dem Verschlüsselungsschlüssel der Bank und möglicherweise einem zusätzlichen symmetrischen Schlüssel.
Nachdem die Bank 30 mit ihrem privaten Schlüssel die Mitteilung vom Verkäufer 20 entschlüsselt hat, überprüft sie dann, dass x₁ nicht bereits in ihrer Datenbank gespeichert ist, und wenn es nicht vorgefunden wird, speichert die Bank 30 dann x₁. Die Bank 30 generiert dann einen Vermerk C(f(x₂)), der eine Geldüberweisung an den Verkäufer 20 für den Betrag des mit f(x₁) assoziierten Werts repräsentiert. Der Vermerk wird dann an den Verkäufer 20 gesandt, der nach Erhalt und Verifizierung die gekauften Güter an den Kunden 10 sendet.
In Wirklichkeit ist dieses verschlüsselte letzte Protokoll mit dem vorhergehenden identisch. Das Hinzufügen von Verschlüsselung hat dem Zahlenden einfach erlaubt die "Zahlungsanweisung" über den Zahlungsempfänger weiterzuleiten, während sichergestellt wird, dass an den geheimen und zusätzlichen, vom Zahlenden bereitgestellten, Informationen nicht herumgepfuscht wird.
Für den Vermerk, C(f(x_i)), könnte es vorteilhaft sein, ein Verfalldatum einzuschließen. In diesem Fall werden die in der Datenbank der Bank 30 gespeicherten x_i nicht zu groß. Das heißt die x_i brauchen nicht für ewig in der Datenbank der Bank festgehalten werden. Um zu verhindern, dass der Wert der Münzen abläuft, könnte die Chipkarte (oder egal was für Ausrüstung die Transaktionen des Kunden handhabt) automatisch die alten Münzen gegen Neue mit einem neuen Verfalldatum austauschen.
Das Verfalldatum macht das Geld außerdem erstattungsfähig. Falls die Chipkarte eines Benutzers funktionsunfähig wird und alle der x_i verloren sind, kann der Benutzer der Bank 30 einfach die f(x_i) mit der Bitte vorlegen, dass, wenn sie nicht innerhalb von 3 Monaten nach dem Verfalldatum beansprucht werden, der Kunde dann den Betrag des Werts der Münzen kreditiert haben möchte. Damit dies funktioniert, muss sich jedoch der Kunde oder die Kundin 10, während der ursprünglichen Kommunikation mit der Bank 30, dann, wenn die Münzen abgehoben werden, identifizieren.
Die Kundenseite der Protokolle lässt sich leicht mit einer Chipkarte durchführen, da nur die x_i gespeichert werden müssen und sie typischerweise nicht viel Speicherkapazität erfordern. Um Diebstahl der x_i durch jemand zu verhindern, der die Chipkarte stiehlt, lässt sich eine PIN in der Chipkarte verwenden, die geheim ist, und die vom Benutzer eingegeben werden muss, bevor Zugriff auf irgendwelche der x_i möglich ist.
Beachten Sie bitte, dass ebenso vorausgesetzt wurde, dass alle der obigen Interaktionen, die oben beschrieben wurden, automatisiert sind. Das heißt sie wurden automatisch von einem entsprechend programmierten Computer oder Prozessor ausgeführt, der unter Kontrolle der Partei stand, für die die Transaktion durchgeführt wurde.
Andere Ausführungsbeispiele befinden sich in den folgenden Ansprüchen. Beispielsweise besteht ein weiterer Weg für das Verbinden identifizierender Informationen mit elektronischen Münzen darin, den geheimen Wert x_i zu benutzen, um das Verbinden auszuführen. In der obigen Beschreibung wurde angenommen, dass die geheimen Werte x_i zufällig vom Erzeuger der Münze generiert werden. Der geheime Wert lässt sich aber als das Bild einiger identifizierenden Daten unter einer Einwegfunktion h(x) generieren, die vielleicht dieselbe Funktion f(x) sein könnte, die bei der Konstruktion normaler elektronischer Münzen benutzt wird. Die identifizierenden Informationen könnten den Zweck und das Datum der Zahlung und den Namen des Zahlenden und des beabsichtigten Zahlungsempfängers einschließen – kurz gesagt, alle Informationen, die der Zahlende vielleicht in der Bank archiviert haben möchte. Diese Informationen würden dann durch h(x) geleitet, um einen x_i zu generieren, der als der geheime Wert dient.
In diesem Fall bestünde für die Bank keine. Notwendigkeit Transaktionsinformationen zu archivieren, die mit elektronischen Zahlungen in entweder den oben beschriebenen Protokollen für „Hinterlegungs-zahlungen" oder Protokollen für "elektronische Zahlungs-anweisungen" empfangen wurden. Tatsächlich ist nur erforderlich, dass die Zahlung dahingehend etikettiert wird, dass der Zahlungsempfänger nicht anonym sein soll. So lang die Bank den Zahlungsempfänger positiv identifiziert und normale Unterlagen der Transaktion, einschließlich der Identität des Zahlungsempfängers, aufbewahrt, kann der Zahlende später "Zahlerstatus" demonstrieren, indem er öffentlich das Urbild von x_i unter f(x) enthüllt, das, wie oben angedeutet, Informationen hinsichtlich Zweck und Datum der Zahlung und die Namen des Zahlenden und des beabsichtigten Zahlungsempfängers einschließen könnte. Der Zahlende kann sich Münzen mit solchen ausdrücklich informationstragenden x_i-Werten einfach beschaffen, in dem er sie normal konstruiert und dann andere Münzen gegen sie austauscht. In diesem Zusammenhang brauchen die Zahlungsinformationen aber nicht an die Bank gesendet werden, da sie ausdrücklich in x_i enthalten sind. Deshalb ist die einzige Information, die der Zahlende sicher an die Bank weiterleiten muss, der öffentliche Unterschriftsschlüssel, der zur Identifizierung des Zahlungsempfängers zu verwenden ist und ausdrücklich die Anforderungen kommuniziert, dass der Zahlende nicht anonym sein soll.
Tatsächlich kann selbst diese letztere Anforderung nach auf Unterschrift beruhender Identifizierung von Zahlungsempfängern eliminiert werden, wenn Information in x_i (oder f(x_i)) eingebettet wird, dass die Bank das Geld nicht auf nicht anonyme Weise einlösen soll. Beispielsweise könnte irgendeine Eigenschaft von x_i (z. B. der Wert des ersten Bits gleich 1) von der Bank öffentlich dahingehend deklariert werden, anzuzeigen, dass die in Frage stehende Münze ausschließlich nicht anonym eingelöst werden wird. Ein Zahlender kann dann ein geheimes x_i generieren, indem er f(s_j) berechnet wobei s_j die Verkettung der Zahlungsinformation für eine beabsichtigte Transaktion mit irgendeinem Zufallswert r ist, der so gewählt wird, dass x_i die Eigenschaft von Nichtanonymität hat. Beachten Sie, dass die Eigenschaft so gewählt werden sollte, dass grob die Hälfte der Urbilder s_j von f(s), irgendeiner speziellen Länge, ein f(s_j) mit der Eigenschaft ergeben, so dass nicht viele Versuche zur Wahl von r notwendig sein werden, bevor einer gefunden wird, der den erwünschen Effekt auf x_i hat. Diese Münze würde jetzt die Eigenschaft haben, dass jemand, der sie zur Einlösung vorlegt, außerdem eine Identität liefern und sie zur Zufriedenheit der Bank nachweisen muss, so dass die Bank die Identität des Austauschenden als Teil ihrer normalen Buchhaltung aufzeichnen kann. Demzufolge würde der Erzeuger der Münze später ihren Ursprung, sowie andere Einzelheiten der Transaktion, bei der ihr Einsatz beabsichtigt war, demonstrieren können, indem er auf die Buchhaltungsunterlagen der Bank verweist und das zum Generieren von x_i verwendete s_j enthüllt. Selbst wenn die Münze völlig normal, ohne zusätzliche Verschlüsselung oder anhängende Information für die Bank ausgegeben wird, versieht sie daher den Zahlenden mit allem Schutz, den die früher beschriebene "elektronische Zahlungsanweisung" liefert.

Claims

Ein elektronisches Geldsystemprotokoll für sichere Transaktionen ohne Ursprungserkennung, gekennzeichnet durch: Verwenden einer öffentlich anzeigepflichtigen Einwegfunktian f₁(x), um ein Bild f₁(x₁) ab einem Urbild x₁ zu generieren; Senden des Bilds f₁(x₁) in einer ungeblendeten Form an eine zweite Partei (30); Empfangen ab der zweiten Partei (30) einer öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einen vorbestimmten Geldbetrag einem ersten Vorleger besagten Urbilds x₁ an die zweite Partei (30) zu kreditieren.
Das elektronische Geldsystempratokoll des Anspruchs 1, werter gekennzeichnet durch Senden des Urbilds x₁ an eine dritte Partei (20) als Zahlung für den Kauf von Gütern oder Dienstleistungen von der dritten Partei (20).
Das elektronische Geldsystemprotokoll des Anspruchs 1 für sichere Transaktionen ohne Ursprungserkennung, weiter gekennzeichnet durch: Selektieren eines zweiten Urbilds x₂; Verwenden einer zweiten öffentlich anzeigepflichtigen Einwegfunktion f₂(x), um ein zweites Bild f₂(x₂) ab des zweiten Urbilds x₂ zu generieren; Senden des ersten Urbilds x₁ und der ungeblendete Form des zweiten Bilds f₂(x₂) an die zweite Partei (30); und Empfangen ab der zweiten Partei (30) einer zweiten öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte zweite öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einem ersten Vorleger besagten zweiten Urbilds x₂ an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren.
Das elektronische Geldsystemprotokoll des Anspruchs 3 für sichere Transaktionen ohne Ursprungserkennung, dadurch gekennzeichnet, dass f₁(x) und f₂(x) dieselbe Funktion sind. Senden des ersten Urbilds x₁ und der ungeblendete Form des zweiten Bilds f₂(x₂) an die zweite Partei (30); und Empfangen ab der zweiten Partei (30) einer zweiten öffentlich anzeigepflichtigen Aufzeichnung einschließlich einer digitalen Unterschrift, wobei besagte zweite öffentlich anzeigepflichtige Aufzeichnung eine Verpflichtung durch die zweite Partei (30) repräsentiert einem ersten Vorleger besagten zweiten Urbilds x₂ an die zweite Partei (30) einen vorbestimmten Geldbetrag zu kreditieren.
Das elektronische Geldsystemprotokoll des Anspruchs 3 für sichere Transaktionen ohne Ursprungserkennung, dadurch gekennzeichnet, dass f₁(x) und f₂(x) dieselbe Funktion sind.