DE69633217T2 - Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels - Google Patents

Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels Download PDF

Info

Publication number
DE69633217T2
DE69633217T2 DE69633217T DE69633217T DE69633217T2 DE 69633217 T2 DE69633217 T2 DE 69633217T2 DE 69633217 T DE69633217 T DE 69633217T DE 69633217 T DE69633217 T DE 69633217T DE 69633217 T2 DE69633217 T2 DE 69633217T2
Authority
DE
Germany
Prior art keywords
user
signature
electronic money
information
amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69633217T
Other languages
English (en)
Other versions
DE69633217D1 (de
Inventor
Eiichiro Yokosuka-shi Fujisaki
Tatsuaki Yokosuka-shi Okamoto
Kazuo Zushi-shi Ohta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP28745795A external-priority patent/JP3171227B2/ja
Priority claimed from JP5753696A external-priority patent/JP3104904B2/ja
Priority claimed from JP5753796A external-priority patent/JP3171228B2/ja
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Application granted granted Critical
Publication of DE69633217D1 publication Critical patent/DE69633217D1/de
Publication of DE69633217T2 publication Critical patent/DE69633217T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3257—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using blind signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ein Verfahren zum Implementieren von elektronischem Geld mittels Austauschen digitaler Information durch die Verwendung eines elektronischen Geldsystems oder von Chipkarten, und insbesondere ein Verfahren zum Implementieren von elektronischem Geld, welches einen Treuhänder verwendet.
  • In der nahen Zukunft wird elektronisches Geld in breiteren Gebrauch kommen, und es wird erwartet, dass Leute Chipkarten als elektronische Brieftaschen verwenden werden, die elektronisches Geld speichern, und Zahlungen für ihre Einkäufe tätigen, indem sie diese Karten in Computer von Geschäften einstecken, oder Überweisungen über das Internet oder dergleichen von Heimcomputern aus tätigen, auf denen elektronisches Geld wie in Bankkonten aufbewahrt ist.
  • Es ist auf jeden Fall wünschenswert, dass elektronisches Geld nicht von irgendeinem physikalischen Medium oder Bedingungen abhängt, so dass die Information selber als das elektronische Geld dient. Bei einem Verfahren, welches elektronisches Geld durch physikalische Mittel gewährleistet, wird sich die Voraussetzung für dessen Sicherheit mit dem Fortschritt der Herstellungstechniken stark ändern. Darüber hinaus kann elektronisches Geld nicht über Kommunikationsleitungen übertragen werden, wenn es immer in Kombination mit einem physikalischen Medium (einer Magnetkarte oder ähnlichem) implementiert ist. Der einfachste Weg, um elektronisches Geld als Information zu übertragen, ist ein elektronisches Kreditzahlungssystem (elektronischer Kredit oder elektronischer Scheck), welches ein elektronisches Unterschriftenschema verwendet (wird später beschrieben). Dieses Verfahren gestattet eine völlige Elektronifizierung (Computerisierung) des gesamten Systems durch die Verwendung einer elektronischen Unterschrift anstatt einer handgeschriebenen Unterschrift und ermöglicht es, dass Information für Zahlungen über Kommunikationsnetzwerke übertragen wird. Dieses System kann jedoch keine Privatsphäre für den Benutzer garantieren; dasselbe trifft auf vorherrschende Kreditkarten- und Schecksysteme zu. D. h., dass Einrichtungen, die Kreditkarten ausgeben und die Bezahlung von Rechnungen des Benutzers abwickeln, leichten Zugang zu deren Kaufhistorien haben und auch Geschäfte die Kreditnummern und Unterschriften des Benutzers leicht erhalten können.
  • Ein konventionelles System, welches die Übertragung von elektronischem Geld als Information erlaubt und die Privatsphäre des Benutzers schützt, ist eines, welches ein Blindunterschriftsystem verwendet (wird später beschrieben). Dieses System ist in zwei Systeme unterteilt: (1) ein System, in welchem das Geschäft, wenn es eine Bezahlung empfängt, sofort elektronisches Geld für eine Online-Überprüfung an eine Bank überträgt, und (2) ein System, in welchem das Geschäft eine provisorische Überprüfung macht und anschließend elektronisches Geld zur normalen Überprüfung an die Bank überträgt. Die hierin erwähnte Überprüfung bedeutet, dass das Geschäft bei der Steuerzentrale (einer Bank) anfragt, ob das vom Kunden vorgelegte elektronische Geld wegen Doppelausgabe und/oder unerlaubter Benutzung keinen monetären Wert besitzt. Weil beim System (1) jedes Geschäft nach jedem Erhalt einer Zahlung auf die Steuerzentrale zugreifen muss, ist dieses System von den Standpunkten der Verarbeitungszeit oder Durchlaufzeit (d. h. Wartezeit des Benutzers), Kommunikationskosten, Online-Verarbeitungskosten bei der Steuerzentrale und Datenbankunterhaltskosten usw., nicht praktikabel. Dementsprechend ist das System (2), welches eine Offline-Verarbeitung erlaubt, für elektronisches Geldsystem bevorzugt.
  • Das Folgende sind konventionelle elektronische Geldsysteme, die der Privatsphäre des Benutzers Bedeutung zuweisen und eine Offline-Verarbeitung ermöglichen.
    • (a) D. Chaum, A. Fiat und M. Naor, „Untraceable Electronic Cash", Advances in Cryptology-Crypto '88, Lecture Notes in Computer Science 403, Seiten 319–327, Springer-Verlag, Berlin (1988)
    • (b) T. Okamoto et al., „Disposable Zero-Knowledge Authentications and Their Applications to Untraceable Electronic Cash", Advances in Cryptology-Crypto '89, Lecture Notes in Computer Science 435, Seiten 481–496, Springer-Verlag, Berlin (1989)
    • (c) T. Okamoto et al., „Universal Electronic Cash", Advances in Cryptology-Crypto '91, Lecture Notes in Computer Science 576, Seiten 324–337, Springer-Verlag, Berlin (1991)
    • (d) T. Okamoto, „An Efficient Divisible Electronic Cash Scheme", Advances in Cryptology-Crypto '95, Springer-Verlag, Berlin (1995)
  • Die elektronischen Geldsysteme, die durch (a) bis (d) typisiert sind, haben untenstehend aufgelistete, ungelöst verbleibende gemeinsame Probleme.
    • 1. Ohne Verletzung der Regeln für die Verwendung von elektronischem Geld (die Regeln für den Systembetrieb), wäre es völlig unmöglich, den Weg oder Fluss des elektronischen Geldes zurückzuverfolgen. Dies bringt die Möglichkeit von Verbrechen wie ungezügeltem Geldwaschen mit sich.
    • 2. In dem Fall, dass Geheimnisse der das elektronische Geld ausgebenden Institution durchsickern, können keine effektiven Maßnahmen getroffen werden, um soziale Unruhen abzubauen. Wenn z. B. ein Entführer der das elektronische Geld ausgebenden Institution die Geheimnisse abpressen sollte, könnte dies ein größeres Problem bedeuten, das mit der oben genannten Nichtverfolgbarkeit des elektronischen Geldes zusammenhängt.
    • 3. Die Menge an Information des elektronischen Geldes ist zu groß, um sie auf Chipkarten oder ähnlichem zu speichern.
  • Die Druckschrift Jan Camenisch et al.: „Fair anonyme Zahlungssysteme", GISI 95-25 25. GI-Jahrestagung und 13. Schweizer Informatikertag (Informatik aktuell), 18.–20. September 1995, Zürich, Seiten 254–265, XP002068945 offenbart ein Verfahren gemäß dem Oberbegriff von Anspruch 1. Gemäß diesem bekannten Verfahren
    • (1) sendet ein Benutzer K ein persönliches Konto np und ein bei einer Bank B eröffnetes anonymes Konto na an einen Treuhänder,
    • (2) empfängt der Treuhänder R die Konten np und na des Benutzers und erzeugt Zufallswerte φ1∊G, α∊Zq, berechnet φ2 = φ1 α und sendet φ1, α, erste und zweite Unterschriften SigR(φ1||np) und SigR(φ2||na) an den Benutzer K;
    • (3) legt der Benutzer K die erste Unterschrift, die Zufallszahl φ1, den Wert v und das persönliche Konto np der Bank B vor,
    • (4) speichert die Bank B φ1 und die erste Unterschrift, wählt ein zufälliges r∊Zq und erzeugt die Information t1 = gr, t2 = φ1 r,
      Figure 00030001
      und sendet t1, t2 und zv an den Benutzer, wobei xv den Geheimschlüssel der Bank bezeichnet und g ein öffentliches Element g∊G ist;
    • (5) berechnet der Benutzer K zv' = zv α, wählt β, γ∊Zq, berechnet t1' = t1gγ, t2' = t2 αβφ2 γ und c' = H(na||cntaK||φ2||zv'||t1'||t2')(modq), inkrementiert den Zähler cntaK um Eins und liefert c = c'/β(modq) an die Bank B,
    • (6) erzeugt die Bank B wiederum das elektronische Geld s = r + cxv(modq) aus c und sendet es an den Benutzer K;
    • (7) berechnet der Benutzer K s' = βs + γ(modq) aus s und sendet v, na, φ2, die zweite Unterschrift und σ = (s', t1', t2', zv') an die Bank B, um v dem anonymen Konto na bei der Bank B gutzuschreiben.
  • Auf Anfrage durch den Benutzer K zieht die Bank B den Wert z vom anonymen Konto na des Benutzers ab und überweist z auf das Konto eines Geschäftes. (Siehe unter „Zahlung an ein Geschäft", Seiten 260–261) Gemäß diesem bekannten Verfahren kann ein Benutzer einen gewünschten Betrag z innerhalb des Wertes v von dem anonymen Konto na auf irgendein Konto bei einer Bank B übertragen, ohne seine Identität zu enthüllen.
  • Die Druckschrift Ernie Brickell, Peter Gemmell, David Kravitz: „Trustee-based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change (chapter 50)", Proceedings of the 6th Annual ACM-SIAM Symposium on Discrete Algorithms, Januar 1995, ACM New York, SIAM Philadelphia, Seiten 457–466, XP002068944 betrifft ein anonymes elektronisches Geldsystem, bei dem zwei miteinander kooperierende Treuhänder in der Lage sind, den Benutzer von elektronischem Geld auf Anfrage durch eine Regierung unabhängig davon, ob das elektronische Geld missbräuchlich verwendet worden ist, zu verfolgen. Die Treuhänder geben keinerlei Lizenz aus.
  • Die Druckschrift Adi Shamir: „How to Share a Secret" Communications of the Association for Computing Machinery, Band 22, Nr. 11, 1. November 1979, Seite 612/613, XP000565227 betrifft ein elektronisches Geldsystem, in dem ein Benutzer K Sätze von Blindunterschrifteninformation Wi, i = 1, ..., K aus geheimer Information Si des Benutzers und zusammengesetzten Nummern Ni = Pi·Qi erzeugt, von denen K/2 Sätze veröffentlicht werden, eine Bank eine Blindunterschrift an die verbleibenden K/2 Sätze der Information anhängt und der Benutzer eine Lizenz aus der Blindunterschrift extrahiert. Der Benutzer erhält eine Blindunterschrift auf die Lizenz und verwendet sie als elektronisches Geld. Ein ähnliches System ist auch in der Druckschrift EP-A-0 391 261 offenbart.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Implementieren von elektronischem Geld bereitzustellen, welches die Teilbarkeit und Übertragbarkeit von elektronischem Geld sicherstellt und die Funktion der Erfassung von Doppelverwendung oder Missbrauch wie im Stande der Technik beibehält und es erlaubt, den Weg des elektronischen Geldes bis zu dessen Ursprung zurückzuverfolgen, und welches dann, wenn Geldwäscherei oder ähnliche strafbare Handlungen befürchtet werden, die Zurückverfolgung des Flusses der Information nur unter der Oberaufsicht oder Autorisierung einer verlässlichen dritten Partei (z. B. eines Gerichts) erlaubt, jedoch normalerweise die Privatsphäre von Benutzern schützt und das Schneid- und Auswahlverfahren (cut-and-choose method) erfordert.
  • Diese Aufgabe wird mit einem Verfahren, wie es im Anspruch 1 beansprucht ist, gelöst. Bevorzugte Ausführungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
  • Wenn gemäß einem ersten Aspekt der vorliegenden Erfindung ein von einer Bank unabhängiger Treuhänder 400 von einem Benutzer aufgefordert wird, seine anonyme öffentliche Information zu registrieren, überprüft ersterer den Namen oder die Identifikationsinformation IDU des Benutzers, bewahrt dann die Entsprechung zwischen der Information N und der Identifikationsinformation IDU als eine Tabelle auf und erzeugt und sendet eine der anonymen öffentlichen Information N entsprechende Unterschrift an den Benutzer. Der Benutzer verwahrt die anonyme öffentliche Information N und die Unterschrift des Treuhänders 400 als eine Lizenz. Der Treuhänder 400 hält die Entsprechung zwischen der Identifikationsinformation IDU des Benutzers und der anonymen öffentlichen Information N geheim. Nur wenn eine vertrauenswürdige dritte Partei (z. B. ein Gericht) die Verfolgung des Flusses der Information verlangt, veröffentlicht der Treuhänder 400 die Entsprechung zwischen der anonymen öffentlichen Information N und der Benutzeridentifikationsinformation IDU.
  • Gemäß einem weiteren Aspekt der Erfindung wird die elektronische Ausgabeprozedur in eine Lizenzausgabeprozedur und eine Ausgabeprozedur für elektronisches Geld aufgeteilt, um die Menge der für das Ausgeben von elektronischem Geld (es wird angenommen, dass die Lizenz für eine feste Zeitdauer gültig ist) zu verarbeitenden Information zu reduzieren. Außerdem wird die Menge der für die Ausgabe der Lizenz zu verarbeitenden Information durch Begrenzen der zum Ausgeben der Lizenz durch den Treuhänder 400 notwendigen Privatsphäre des Benutzers reduziert.
  • Gemäß einem weiteren Aspekt der Erfindung zahlt der Benutzer elektronisches Geld C mit dem Wert X in einem gewünschten Betrag für jeden Einkauf durch Erzeugen einer Unterschrift, welche die Zahlung eines Betrags x (wobei x ≤ X) garantiert.
  • Gemäß einem weiteren Aspekt der Erfindung kann ein weiterer Benutzer, der den Betrag x erhält, diesen für eine Zahlung oder für eine weitere Übertragung verwenden, wenn der Benutzer eine Unterschrift erzeugt, welche die Übertragung eines Betrages x (wobei x ≤ X) garantiert.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung kann der Treuhänder in eine Mehrzahl von unabhängigen Institutionen aufgeteilt werden, um eine erhöhte Sicherheit für den Benutzer bereitzustellen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockdiagramm, das die allgemeine Konfiguration eines Systems zum Implementieren von elektronischem Geld, das die vorliegende Erfindung verkörpert, darstellt;
  • 2 ist ein Blockdiagramm, das eine Lizenzausgabeverarbeitung zeigt, die zwischen einem Benutzer und einem Treuhänder in 1 gemäß einer ersten Ausführung der vorliegenden Erfindung ausgeführt wird;
  • 3 ist ein Blockdiagramm, das eine Ausgabeverarbeitung für elektronisches Geld zwischen dem Benutzer und einer Bank in 1 zeigt;
  • 4 ist ein Blockdiagramm, das eine Verarbeitung durch den Benutzer zum Zahlen mit elektronischem Geld an ein Geschäft in 1 zeigt;
  • 5 ist ein Blockdiagramm, das eine Verarbeitung durch das Geschäft zum Empfangen der Zahlung mit elektronischem Geld in 1 zeigt;
  • 6 ist ein Blockdiagramm, das eine Verarbeitung für die Abrechnung zwischen dem Geschäft und der Bank in 1 zeigt;
  • 7 ist ein Blockdiagramm, das eine Verarbeitung durch den Benutzer 200 zum Übertragen von elektronischem Geld vom Benutzer 200 an einen anderen Benutzer 500 in 1 zeigt;
  • 8 ist ein Blockdiagramm, das eine Verarbeitung durch den Benutzer 500 zum Übertragen von elektronischem Geld vom Benutzer 200 an den Benutzer 500 in 1 zeigt;
  • 9 ist ein Blockdiagramm, das eine Verarbeitung durch den zweiten Benutzer 500 zum Bezahlen mittels an das Geschäft übertragenem elektronischem Geld in 1 zeigt;
  • 10 ist ein Diagramm, das eine Lizenzausgabeprozedur in einer zweiten Ausführung der vorliegenden Erfindung zeigt;
  • 11 ist ein Diagramm, das eine Ausgabeprozedur für elektronisches Geld der zweiten Ausführung zeigt;
  • 12 ist ein Diagramm, das eine Prozedur für die Zahlung an das Geschäft mit elektronischem Geld der zweiten Ausführung zeigt;
  • 13 ist ein Diagramm, das eine Teilübertragungsprozedur für elektronisches Geld der zweiten Ausführung zeigt;
  • 14 ist ein Diagramm, das eine Prozedur für die Teilübertragung von elektronischem Geld in der zweiten Ausführung zeigt;
  • 15 ist ein Diagramm, das die Systemkonfiguration darstellt, in welcher eine Mehrzahl von Treuhändern die Lizenzausgabeverarbeitung auf einer verteilten Basis gemäß einer dritten Ausführung ausführt;
  • 16 ist ein Funktionsblockdiagramm, das die Verarbeitung durch den Benutzer 200 in der Lizenzausgabeprozedur zeigt;
  • 17 ist ein Funktionsblockdiagramm, das die Verarbeitung durch Treuhänder 40T1 bis 40Tt bei der Lizenzausgabeprozedur zeigt;
  • 18 ist ein Diagramm, das die Verarbeitung zum Verfolgen des Benutzers auf der Basis der Information (N, B) und zum Verfolgen der Information (N, B) auf der Basis der Identität des Benutzers erläutert;
  • 19 ist ein Diagramm, das eine Systemkonfiguration zum Registrieren von Zufallswerten mit einer Mehrzahl von Treuhändern in einer vierten Ausführung zeigt;
  • 20 ist ein Blockdiagramm, das die funktionale Konfiguration für die Ausgabeverarbeitung von elektronischem Geld zwischen dem Benutzer und der Bank in 19 darstellt;
  • 21 ist ein Blockdiagramm, das die funktionale Konfiguration für die Ausgabeverarbeitung von elektronischem Geld zwischen der Bank und Treuhändern in 19 darstellt; und
  • 22 ist ein Blockdiagramm, das die funktionale Konfiguration zur Missbrauchsverfolgungsverarbeitung durch die Treuhänder und das Geschäft in 19 darstellt.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNG
  • Einführung
  • Das wichtigste Merkmal der vorliegenden Erfindung ist, dass ein Treuhänder unabhängig von einer Bank Lizenzen an einzelne Benutzer ausgibt, und eine Entsprechungstabelle von Identifikationsin formation IDU1, IDU2, ..., die von den Benutzern empfangen wird, und deren anonymer öffentlicher Schlüsselinformation N1, N2, ... erstellt und verwahrt. Ein weiteres wichtiges Merkmal der vorliegenden Erfindung liegt darin, dass die Bank elektronisches Geld C entsprechend einer Unterschrift B des Treuhänders und dessen spezifiziertem Betrag X ausgibt. Daher kann die Bank nicht von sich aus die Beziehung zwischen der Identifikationsinformation IDU des Benutzers und dessen anonymem öffentlichem Schlüssel N verfolgen. Der Treuhänder kann ebenfalls nicht von sich aus die Beziehung zwischen der Identifikationsinformation IDU des Benutzers und dem elektronischen Geld C verfolgen. Z. B. ist es im Fall einer Transaktion, bei der Verdacht auf eine Straftat wie Geldwäscherei besteht, jedoch möglich, den Benutzer, der die Transaktion ausgeführt hat, zu spezifizieren, indem man die Bank aufgrund eines Gerichtsbefehls oder etwas ähnlichem veranlasst, eine Historie der Transaktionen vorzulegen, den anonymen öffentlichen Schlüssel N aus der Historie extrahiert und die Identifikationsinformation IDU des Benutzers entsprechend dem öffentlichen Schlüssel N mit dem Beistand des Treuhänders erhält.
  • Das elektronische Geldsystem gemäß der vorliegenden Erfindung umfasst vier Institutionen mit unterschiedlichen Zwecken wie z. B. einen Treuhänder, einen Benutzer, eine Bank und ein Geschäft, und es hat sieben Phasen der Zahlung, der Übertragung, der Konversion und der Verwaltung von elektronischem Geld und der Erfassung eines Angreifers.
  • Bei der vorliegenden Erfindung erstellen der Treuhänder, der Benutzer und die Bank digitale Unterschriften. Der Treuhänder und der Benutzer können willkürliche digitale Unterschriftensysteme verwenden, während die Bank ein digitales Unterschriftensystem verwenden kann, welches es ihr ermöglicht, ein Blindunterschriftsystem zu verwenden.
  • Digitale Unterschrift
  • Die hierin erwähnte digitale Unterschrift (oder elektronische Unterschrift) ist eine solche, die durch digitale Verarbeitung an gewünschte digitale Information angehängt wird, und sie ist einer Unterschrift oder einem Siegel funktional äquivalent, die gewöhnlicherweise auf einem Schriftstück aufgebracht werden. Mit anderen Worten bedeutet die an eine gewisse elektronische Information angehängte Unterschrift, dass der Unterzeichner für die Inhalte der elektronischen Information garantiert. Der Abschluß eines Vertrages über ein elektronisches Mailsystem oder das Einrichten eines WWW (World Wide Web) Kredites per Internet, das derzeit in weiten Gebrauch gelangt, ist ein Beispiel dafür, wofür das digitale Unterschriftensystem angewendet werden kann.
  • Im Allgemeinen hat die digitale Unterschriftenprozedur drei Phasen der Registrierung, Erzeugung und Verifikation der Unterschrift. Darüber hinaus schließt das digitale Unterschriftenschema Information, die gewöhnlich ein Geheimschlüssel und ein öffentlicher Schlüssel genannt wird, ein. Es wird eine Beschreibung der digitalen Unterschrift (nachfolgend als eine Unterschrift bezeichnet) für die Verwendung in der vorliegenden Erfindung gegeben.
  • Algorithmen für die Erzeugung und Verifikation einer Unterschrift und öffentliche Parameter werden im Voraus veröffentlicht.
    • (1) Schlüsselregistrierung: Jeder Unterzeichner hat einen Geheimschlüssel P und einen öffentlichen Schlüssel N und registriert den öffentlichen Schlüssel N in einem öffentlichen Schlüsselregister. Der öffentliche Schlüssel N muss für jeden Unterzeichner einzigartig sein. Dies ist die Registrierung des Schlüssels. Der Schlüssel muss nicht immer registriert werden, was später beschrieben wird.
    • (2) Unterschrifterzeugung: Eine elektronische Nachricht m und der Geheimschlüssel P des Unterzeichners werden in den Unterschrifterzeugungsalgorithmus eingegeben, wodurch eine Unterschrift s erzeugt wird. Wenn der Unterschrifterzeugungsalgorithmus als eine Funktion betrachtet wird, ist der Geheimschlüssel des Unterzeichners ein Parameter dieser Funktion und die Nachricht m repräsentiert den Eingabewert der Funktion.
    • (3) Unterschriftverifikation: Die elektronische Nachricht m, die Unterschrift s und der öffentliche Schlüssel N werden in den Unterschriftverifikationsalgorithmus eingegeben, wobei OK/NG ausgegeben wird. Dies bedeutet, es ist verifiziert, dass die Unterschrift s zu der Nachricht m von einer Person gemacht wurde, die ihren öffentlichen Schlüssel N registriert hat.
  • Es muss an dieser Stelle beachtet werden, dass jedermann die Gültigkeit der Unterschrift verifizieren kann, weil der öffentliche Schlüssel N im öffentlichen Schlüsselregister registriert ist, aber dass nur der Unterzeichner, der den Geheimschlüssel P kennt, die Unterschrift erzeugen kann.
  • Es wurden viele digitale Unterschriftensysteme wie etwa die unten stehend aufgelisteten vorgeschlagen.
    • (1) RSA-Schema von Herrn Rivest et al. (R. L. Rivest, „A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications on ACM Band 2, Seiten 120 – 126, 1978)
    • (2) Schema beschrieben in T. Okamoto, „A Fast Signature Scheme Based on Congruential Polynomical Operations", IEEE Transactions on Information Theory, Band IT-36, Nr. 1, Seiten 47–53 (Januar 1990) (Dieses wird nachfolgend als ein "ESIGN"-Schema bezeichnet.)
    • (3) Schema beschrieben in A. Fiat und A. Shamir, „How to Prove Yourself: Practical Solutions to Identification and Signature Problems", in Advances in cryptology-CRYPT '86, Proceedings, LNCS 263, Springer Verlag, Berlin, Seiten 186–194 (1987) (Dies wird nachfolgend als ein "FS"-Schema bezeichnet.)
    • (4) Schema beschrieben in S. Micali und A. Shamir, „An Improvement of the Fiat-Shamir Identification and Signature Scheme", Proceedings of CRYPTO '88, LNCS 403, Springer Verlag, Seiten 244–247 (1990) (Dies wird nachfolgend als ein "MS"-Schema bezeichnet.)
    • (5) Schema beschrieben in K. Ohta und T. Okamoto, „a Modification of the Fiat-Shamir Scheme", Proceedings of Crypto '88, LNCS 403, Springer Verlag, Seiten 232–243 (1990) (Dies wird nachfolgend als ein "OO"-Schema bezeichnet.)
    • (6) Schema beschrieben in T. Okamoto, „Provably secure and Practical Identification Schemes and corresponding Signature Schemes", zu Erscheinen in der Proc. of Crypto '92 (Dies wird nachfolgend als ein "Oka"-Schema bezeichnet.).
    • (7) Schema beschrieben in C. P. Schnorr, „Efficient signature generation by smart cards", Journal of Cryptology, Band 4, Nr. 3, Seiten 161–174 (1991) (Dies wird nachfolgend als ein „Sch"-Schema bezeichnet.)
  • Die digitale Unterschrift erfordert nicht immer das öffentliche Schlüsselregister. Es ist auch ein Schema verfügbar, bei dem das Verwaltungszentrum den öffentlichen Schlüssel N hinzuaddiert, anstatt ihn zu registrieren. Es ist natürlich notwendig, dass der öffentliche Schlüssel des Verwaltungszentrums in irgendeinem öffentlichen Schlüsselregister ist.
  • Als nächstes wird eine Beschreibung der grundlegenden Prozedur der „RSA-", „ESIGN-" und „OO-"Schemata gegeben, die typisch sind für das digitale Unterschriftensystem, welches der Treuhänder 400 und ein Benutzer 200 in der vorliegenden Erfindung verwenden.
  • (A) RSA-Schema
    • (1) Schlüsselregistrierung: Wenn er am elektronischen Geldsystem teilnimmt, erzeugt ein Unterzeichner A d = e–1mod(p – 1, q – 1), n = pq aus zwei ganzen Zahlen p und q, behält (d, n) als einen Geheimschlüssel, wobei er (e, n) als einen öffentlichen Schlüssel in einem öffentlichen Schlüsselregister registriert.
    • (2) Unterschrifterzeugung: Ein Unterzeichner A berechnet eine Unterschrift s(s, Zn*) aus Geheiminformation (d, n) und einer Nachricht m durch die folgende Gleichung mittels einer Hash-Funktionsberechnung (einer Einwegfunktionsberechnung) und einer Modulo-Multiplikation s = f(m)dmodnund sendet ein Paar mit m und s an einen Prüfer B. Im Obigen ist f(m) ein Wert (f(m)∊Zn), der von der Hash-Funktionsberechnung erzeugt wird. Ein Beispiel für die Implementierung oder Realisierung der Hash-Funktion wird z. B. in R. L. Rivest, „Applying the RSA Digital Signature to Electronic Mail", IEEE Computer, Seiten 55–62, 1983 vorgestellt.
    • (3) Unterschriftverifikation: Der Prüfer B macht eine Überprüfung, ob die Unterschrift s eine gültige Unterschrift der Nachricht m des Unterzeichners A ist, indem er überprüft, ob sie die folgende Verifikationsgleichung erfüllt. Der Prüfer B erzeugt f(m) mittels der Hash-Funktionsberechnung aus der Nachricht m und verifiziert die folgende Gleichung mittels einer Modulo-Multiplikation und einem Vergleich. Se ≡ f(m)(modn)
  • Wenn die Verifikation erfolgreich ist, akzeptiert der Prüfer B die unterzeichnete Nachricht als gültig (OK) und falls nicht, weist er sie als ungültig (NG) zurück.
  • (B) "ESIGN"-Schema
    • (1) Schlüsselregistrierung: Wenn der Unterzeichner A dem System beitritt, erzeugt er zwei ganze Zahlen p und q als einen Geheimschlüssel und hält sie geheim, er erzeugt einen öffentlichen Schlüssel n = p2q und registriert n im öffentlichen Schlüsselregister.
    • (2) Unterschrifterzeugung: Die folgende Beschreibung wird für den Fall gegeben, bei dem der Unterzeichner A die Nachricht m unterzeichnet. Der Unterzeichner A berechnet die durch die Hash-Funktionsberechnung aus der öffentlichen Information n und der Nachricht m erzeugte Unterschrift s (s∊Zn*) für f(m) (wobei f(m)∊Zn) und sendet ein Paar mit der Nachricht m und der Unterschrift s an den Prüfer B. In erster Linie erzeugt der Unterzeichner A eine Zufallszahl t∊Zpq* und berechnet daraus das folgende w mittels einer rationalen Modulo-Operation, einer Subtraktion, einer Division und einer Rundungsoperation. w = ⌈{f(m)–(tkmodn)}/pq⌉Nebenbei bemerkt bedeutet [a] den kleinsten ganzzahligen Wert, der größer ist als a (in dieser Anmeldung wird eine dieses Symbol ausführende Operation eine „Rundungsoperation" genannt). Dem folgt eine Berechnung von u, welches die folgende Gleichung erfüllt. w ≡ ktk–1u(modp)Um diese Gleichung zu erhalten, wird die folgende Berechnung gemacht. u = (ktk–1)–1wmodpSchließlich wird die Unterschrift s durch die folgende Operation berechnet. s = t + upq
    • (3) Unterschriftverifikation: Der Prüfer B verifiziert die Gültigkeit der Unterschrift s zu der Nachricht m des Unterzeichners durch Überprüfen, ob sie die folgende Verifikationsgleichung erfüllt. Der Prüfer B erzeugt f(m) mittels der Hash-Funktionsoperation aus der Nachricht m und verifiziert sie durch die folgende rationale Modulo-Operation und einen Vergleich. f(m) ≤ skmodn < f(m) + 22|n|/3
  • Wenn die Verifikation erfolgreich ist, wird die unterzeichnete Nachricht als gültig (OK) akzeptiert, und falls nicht, als ungültig (NG) abgewiesen.
  • (C) "OO"-Schema
  • Öffentliche Parameter seien durch n und L repräsentiert.
    • (1) Schlüsselregistrierung: Wenn er an dem System teilnimmt, wählt der Unterzeichner A eine ganze Zahl x∊Zn, berechnet h = xLmodn, behält x als einen Geheimschlüssel und registriert h als einen öffentlichen Schlüssel in dem öffentlichen Schlüsselregister.
    • (2) Unterschrifterzeugung: Der Unterzeichner A erzeugt eine Zufallszahl r∊Zn, erhält a = rLmodnmittels einer Modulo-Multiplikation und einer Modulo-Exponentialberechnung, erhält c = f(m||a)durch die Hash-Funktionsoperation aus der Nachricht m, erhält s = rxcmodnund sendet (m, a, s) an einen Prüfer B.
    • (3) Unterschriftverifikation: Der Prüfer B überprüft die Gültigkeit der Unterschrift (a, s) zu der Nachricht m des Unterzeichners durch Überprüfen, ob sie folgende Verifikationsgleichung erfüllt. sL ≡ ahf(m|a)(modn)
  • Wenn die Verifikation erfolgreich ist, akzeptiert der Prüfer B die unterzeichnete Nachricht als gültig (OK), und falls nicht, weist er sie als ungültig (NG) zurück.
  • Blindunterschrift
  • In solchen digitalen Unterschriftensystemen, wie sie oben beschrieben sind, kann es manchmal möglich sein, den Unterzeichner seine Unterschrift zu der Nachricht m hinzufügen zu lassen und dabei ihre Inhalte geheim zu halten. Die auf diese Weise vom Unterzeichner erhaltene Unterschrift wird eine Blindunterschrift genannt. In Kombination mit einem elektronischen Geldsystem oder etwas Ähnlichem spielt diese Technik eine wichtige Rolle für das Schützen der Privatsphäre des Benutzers. Die vorliegende Erfindung führt ein Blindunterschriftprotokoll beim Abheben von elektronischem Geld von einer Bank ein. Es wird eine allgemeine Beschreibung der Blindunterschrift gegeben.
  • Eine Person B, welche die Blindunterschrift anfragt, erzeugt eine Blindnachricht m' aus der Nachricht m durch eine Blindunterschriftvorverarbeitung. Der Unterzeichner A berechnet durch Verwen dung des Geheimschlüssels eine provisorische Unterschrift s', die der Blindnachricht m' entspricht. Die anfragende Person B berechnet das wahre Signal s, das der ursprünglichen Nachricht m entspricht, aus der provisorischen Unterschrift s' durch Blindunterschriftnachverarbeitung. Der Unterzeichner A hängt die provisorische Unterschrift an die Nachricht m ohne Wissen über deren Inhalte an, jedoch ist die aus der provisorischen Unterschrift s' abgeleitete Unterschrift s identisch mit der wahren Unterschrift des Unterzeichners A; daher kann der Prüfer die Gültigkeit der Unterschrift, die der Nachricht m angefügt ist, durch Verwenden des öffentlichen Schlüssels des Unterzeichners A verifizieren.
  • Ein Blindunterschriftsystem, das auf dem RSA-Schema basiert, ist in D. Chaum, „Security without Identification: Transaction Systems to Make Big Brother Obsolete", Comm. of the ACM, 28, 10, Seiten 1030–1044 (1985), beschrieben, und ein Blindunterschriftsystem, das auf einem interaktiven Beweis mit Null-Wissen basiert, ist in T. Okamoto et a., „Divertible Zero-Knowledge Interactive Proofs and Commutative Random Self-Reducible", The Proc. of Eurocrypt '89 (1989); offenbart. Das erstere System erlaubt die Implementierung der Blindunterschrift in dem [RSA]-Schema, und das letztere System in den [FS]-, [MS]-, [OO]- und [Oka]-Schemata.
  • (A) Blindunterschrift durch [RSA]-Schema
  • Eine anfragende Person B erzeugt eine Zufallszahl r durch einen Zufallsgenerator, berechnet dann Z durch Hash-Operation, Modulo-Exponentialberechnung und Modulo-Multiplikation aus der Zufallszahl r und der Nachricht m, und sendet sie an den wahren Unterzeichner A. Z = f(m)remodn
  • Der Unterzeichner A verwendet den Geheimschlüssel (d, n), um Θ = Zdmodndurch Modulo-Exponentialberechnung zu erhalten, und sendet ihn an die anfragende Person B.
  • Die anfragende Person B kann die wahre Unterschrift s durch Verwendung des öffentlichen Schlüssels (e, n), eines inversen Modulo-Rechners und eines Modulo-Multiplizierers berechnen. s = Θ/rmodnwobei s = f(m)dmodn und s die wahre Unterschrift der Nachricht m ist.
  • (B) Blindunterschrift basierend auf interaktiven Beweisen mit Null-Wissen durch [OO]-Schema
  • Um die Anfrage von der anfragenden Person B zu erfüllen, erzeugt der Unterzeichner A einen Zufallswert r, erhält dann a' = rLmodndurch Modulo-Exponentialberechnung und sendet es an die anfragende Person B.
  • Die anfragende Person B erzeugt Zufallswerte r' und b und erhält a = a'r'Lhbmodndurch Modulo-Exponentialberechnung und Modulo-Multiplikation. Darüber hinaus berechnet die anfragende Person B c = f(m||a)modndurch Hash-Operation und berechnet c' = c + bmodLdurch Addition, Subtraktion und Modulo-Operation und sendet es an den Unterzeichner A.
  • Der Unterzeichner A erhält s' = rxcmodndurch Modulo-Exponentialberechnung und Modulo-Multiplikation aus dem öffentlichen Schüssel h und dem Geheimschlüssel x, und sendet es an die anfragende Person B.
  • Die anfragende Person B berechnet d durch Addition, Subtraktion und Modulo-Multiplikation, welche die folgende Gleichung erfüllt c' = c + b + dLund berechnet s = s'r'h–dmodndurch Modulo-Exponentialberechnung und Modulo-Multiplikation. Hier wird (a, s) identisch mit der wahren Unterschrift, die der Nachricht m angefügt ist.
  • Erste Ausführung
  • 1 stellt eine grundlegende Konfiguration einer ersten Ausführung eines solchen elektronischen Geldsystems, wie es oben beschrieben ist, dar. Bei dieser Ausführung ist elektronisches Geld teilbar und übertragbar. Das elektronische Geldsystem der 1 umfasst einen Treuhänder 400, eine Bank 100, einen Benutzer 200, ein Geschäft 300 und einen weiteren Benutzer 500, die über Kommunikationsleitungen untereinander verbunden sind, die aber auch über eine Chipkarte oder etwas ähnliches, auf dem Information aufgezeichnet sein kann, miteinander verbunden sein können.
  • Als erstes wird mit Bezugnahme auf 1 eine Beschreibung des grundlegenden Prinzips der vorliegenden Erfindung gegeben. Das wichtigste Merkmal der vorliegenden Erfindung besteht darin, dass der von der Bank 100 unabhängige Treuhänder 400 eine Lizenz B an jeden Benutzer 200 ausgibt, eine Entsprechungstabelle der Identifikationsinformation IDU, die von den Benutzern 200 empfangen wird, und deren anonymer öffentlicher Information oder Pseudonymen I erstellt und unterhält, während die Bank 100 an den Benutzer 200, welcher die Lizenz B und einen Geldbetrag X vorlegt, elektronisches Geld C entsprechend dem spezifizierten Betrag X ausgibt. Dementsprechend kann die Bank 100 nicht von der Beziehung zwischen der Identifikationsinformation IDU des Benutzers 200 und seiner öffentlichen Information N erfahren. Der Treuhänder 400 kann ebenfalls nicht die Beziehung zwischen der Identifikationsinformation IDU des Benutzers und dem elektronischen Geld C erfahren. Wie jedoch später beschrieben wird, ist es in Fällen des Verfolgens einer Transaktion (Zahlung) bei Verdacht auf eine Straftat wie Geldwäscherei mit der Genehmigung eines Gerichtes möglich, den Benutzer 200, der mit der Transaktion in Beziehung steht, zu spezifizieren, indem man der Bank 100 die anonyme öffentliche Information N in einer Kommunikationshistorie, d. h. Zahlungshistorie H, betreffend die Transaktion, und dem Treuhänder 400 die Identifikationsinformation IDU des Benutzers entsprechend der anonymen öffentlichen Information N vorlegt.
  • Das grundlegende Verfahren von der Ausgabe der Lizenz bis zur Ausgabe des elektronischen Geldes ist wie folgt:
  • Schritt S11: Der Benutzer 200 sendet seine Identifikationsinformation IDU und anonyme öffentliche Information N an den Treuhänder 400.
  • Schritt S12: Der Treuhänder 400 hält die Entsprechung zwischen der Identifikationsinformation IDU und der anonymen öffentlichen Information N des Benutzers als eine Tabelle 41T geheim, erzeugt dann eine Unterschrift B des Treuhänders 400 für die anonyme öffentliche Information N und sendet sie an den Benutzer 200 (Ausgabe der Lizenz).
  • Schritt S13: Der Benutzer 200 speichert die Unterschrift B des Treuhänders 400 als die Lizenz, legt dann die Lizenz B und einen Geldbetrag X der Bank 100 vor und bittet die Bank, das elektronische Geld c, das den Betrag X wert ist, auszugeben.
  • Schritt S14: Die Bank 100 gibt das elektronische Geld C, das mit der Lizenz B in Beziehung steht und den Betrag X wert ist, an den Benutzer 200 aus (Ausgabe von elektronischem Geld).
  • Als nächstes wird ein grundlegendes Verfahren für die Verwendung von elektronischem Geld beschrieben.
  • Schritt S21: Der Benutzer 200 legt die anonyme öffentliche Information N, die Lizenz B und das elektronische Geld C dem Geschäft 300 vor. Darüber hinaus erzeugt der Benutzer 200 durch Verwenden der anonymen öffentlichen Information N eine Unterschrift S, welche die Zahlung des Betrages von verwendetem Geld x (wobei x ≤ X) sicherstellt, und sendet die Unterschrift S an das Geschäft 300, wodurch er die Zahlung macht (Zahlung von elektronischem Geld).
  • Schritt S22: Das Geschäft 300 rechnet ab, indem es die Zahlungshistorieninformation H an die Bank 100 sendet, und den Geldbetrag, der dem Betrag x entspricht, empfängt (Konvertierung von elektronischem Geld).
  • Schritt 23: Die Bank 100 überprüft, ob die Gesamtsumme der Zahlung mit dem elektronischen Geld C innerhalb der Grenze X liegt (Verwaltung von elektronischem Geld), und wenn der Gesamtbetrag die Grenze X übersteigt, extrahiert die Bank 100 wenigstens die anonyme öffentliche Information N aus einer Historie der Zahlung mit dem elektronischen Geld C und sendet sie an den Treuhänder 400.
  • Schritt S24: Wenn sie Instruktionen von einer offiziellen dritten Partei erhält, fragen die Bank 100 und der Treuhänder 400 jeweils die Identifikationsinformation und den anonymen öffentlichen Schlüssel des Benutzers, der durch die offizielle dritte Partei bezeichnet ist, aus einer Kommunikationshistorie, die unter der Aufsicht der Bank 100 steht, und der vom Treuhänder 400 gehaltenen Entsprechungstabelle ab, und sie senden die abgefragte Information an die offizielle dritte Partei.
  • Aufgrund der empfangenen öffentlichen Information N kann der Treuhänder 400 die Entsprechung zwischen dem Benutzer 200 in der Entsprechungstabelle 41T und der anonymen öffentlichen Information N veröffentlichen, es kann aber eine gewöhnliche Abrechnung mit der Bank gemacht werden, ohne den Namen des Benutzers offenzulegen.
  • Bei der Konfiguration des grundlegenden Prinzips der vorliegenden Erfindung, wie in 1 gezeigt, erzeugt der Treuhänder 40 die Unterschrift B im Schritt S12, dann erzeugt die Bank 100 das elektronische Geld C, das von der Bank 100 blind im Schritt S14 unterschrieben ist, und der Benutzer 200 erzeugt die digitale Unterschrift S, die dem Geschäft 300 die Zahlung des Geldbetrages x im Schritt S21 versichert. Weil diese digitale Unterschriftprozedur (einschließlich der Blindunterschrift) jeweils zwischen dem Treuhänder 400 und dem Benutzer 200, zwischen der Bank 100 und dem Benutzer 200, und zwischen dem Benutzer 200 und dem Geschäft 300 abgeschlossen wird, können digitale Unterschriftsysteme von jeglicher Art eingesetzt werden.
  • Als nächstes wird ein spezifisches Betriebsbeispiel der vorliegenden Erfindung beschrieben.
  • Vorab-Prozedur
  • Im elektronischen Geldsystem der ersten Ausführung lässt sich der Benutzer des elektronischen Geldes zuerst eine Lizenz von einer Treuhänder genannten Institution erteilen. Die Bank (welche das elektronische Geld ausgibt und bezahlt und in der Praxis irgendein Typ von Finanzeinrichtung sein kann) erfüllt die Aufforderung des Benutzers, elektronisches Geld an den Benutzer auszugeben, das einen gewissen Geldbetrag wert ist. Der Benutzer verwendet das elektronische Geld, um Zahlungen an Geschäfte zu machen, bis der Nennwert des elektronischen Geldes erreicht ist. Schließlich rechnet jedes Geschäft jede Zahlung des Benutzers mit der Bank ab.
  • Während der Treuhänder 400, der Benutzer 200 und die Bank 100 irgendeinen der oben beschriebenen elektronischen Unterschriftenalgorithmen verwenden können, wird die folgende Beschreibung unter der Annahme gemacht, dass sie alle den RSA-Unterschriftenalgorithmus verwenden, und dass die Paare aus Geheimschlüsseln und öffentlichen Schlüsseln für deren Verwendung (dB, nB) und (eB, nB) für den Treuhänder (für Lizenz), (dC, nC) und (eC, nC) für die Bank (für elektronisches Geld) und (d, N) und (e, N) für den Benutzer sind. Der öffentliche Schlüssel N des Benutzers 200 ist anonyme öffentliche Information.
  • Die Unterschrift des Treuhänders 400 und die Unterschrift der Bank 100 werden jeweils verwendet, um die Gültigkeit der Lizenz bzw. des elektronischen Geldes zu überprüfen. In den Unterschriften des Benutzers kann e im öffentlichen Schlüssel allgemein gemacht werden, jedoch ist die anonyme öffentliche Information, welche eine zusammengesetzte Zahl ist, als das Produkt aus zwei geheimen Primzahlen für jeden Benutzer definiert.
  • Wenn es gewünscht ist, dass der Nennwert des elektronischen Geldes, das von der Bank 100 ausgegeben werden soll, in eine Mehrzahl von Geldbeträgen aufgeteilt wird, werden ein Paar aus geheimem und öffentlichem Schlüssel (dC, nC) und (eC, nC) entsprechend jedem Geldbetrag vorbereitet und zusammen mit dem Geldbetrag (eC, nC) der Öffentlichkeit offengelegt. Darüber hinaus werden auch Einwegfunktionen (Hash-Funktionen) g und h für die Verwendung von Unterschriften definiert und im Voraus veröffentlicht.
  • Prozedur der Lizenzausgabe
  • 2 erläutert die Prozedur für den Benutzer 200, um vom Treuhänder 400 die Lizenz ausgegeben zu bekommen. Jeder Benutzer führt diese Prozedur nur einmal für die Registrierung der zusammengesetzten Zahl N aus.
  • Schritt 1: Der Benutzer 200 erzeugt zwei große Primzahlen P und Q mittels eines Primzahlengenerators 210 und berechnet mittels eines Multipliziers die zusammengesetzte Zahl N (N = P × Q) 211, welche als die anonyme öffentliche Information N verwendet wird. Ein weiterer öffentlicher Schlüssel e des RSA-Schemas ist allen Benutzern bekannt und wird beispielsweise auf einen Wert 3 gesetzt. Darüber hinaus berechnet der Benutzer 200 d = e–1modLCM(P – 1, Q – 1) (1)aus e, P und Q mittels eines inversen Modulo-Rechners 212 und speichert d und N in einem Speicher 20M.
  • Schritt 2: Der Benutzer 200 überträgt die zusammengesetzte Zahl N zusammen mit der Benutzeridentifikationsinformation IDU an den Treuhänder 400.
  • Schritt 3: Der Treuhänder 400 verifiziert die Identität des Benutzers 200 durch irgendein Verfahren. Wenn die Verifikation erfolgreich ist, erzeugt der Treuhänder 400 als ein Pseudonym I Information wie z. B. die Gültigkeitsdauer der Lizenz durch einen Pseudonymgenerator 410, schreibt dann die Entsprechung der Identifikationsinformation IDU des Benutzers 200 mit dem Pseudonym I und dem öffentlichen Schlüssel N in die Entsprechungstabelle 41T und hält sie geheim.
  • Schritt 4: Der Treuhänder 400 führt die folgende Unterschriftberechnung mittels eines g-Rechners 412 und eines Modulo-Exponentialrechners 413 aus.
  • Figure 00170001
  • Der Treuhänder 400 überträgt die Unterschrift B und das Pseudonym I an den Benutzer 200.
  • Schritt 5: Der Benutzer 200 speichert die Daten B und I, die er vom Treuhänder 400 empfangen hat und die anonyme öffentliche Information N als eine Lizenz (B, I, N) im Speicher 20M.
  • Für den Fall, dass die oben genannte Information über eine Kommunikationsleitung ausgetauscht wird, ist es bevorzugt, die individuelle Information zu verschlüsseln.
  • Prozedur zur Ausgabe von elektronischem Geld
  • Als nächstes wird mit Bezugnahme auf 3 eine Beschreibung der Prozedur für den Benutzer 200 gegeben, um das elektronische Geld C von der Bank 100 ausgegeben zu bekommen. In diesem Beispiel ist (eC, nC) ein öffentlicher Schlüssel für die digitale Unterschrift der Bank, welche dem vom Benutzer 200 spezifizierten Nennwert X (z. B. 10.000 Yen) des elektronischen Geldes entspricht.
  • Schritt 1: Der Benutzer 200 erzeugt einen Zufallswert b mittels eines Zufallswertgenerators 220 und speichert ihn in dem Speicher 20M, während der Benutzer 200 zur selben Zeit g(B||b) mittels eines g-Rechners 221 aus dem Zufallswert b und der Lizenz (B, I, N), die aus dem Speicher 20M ausgelesen wird, berechnet. Darüber hinaus führt der Benutzer 200 eine Blindunterschriftvorverarbeitung der folgenden Gleichung mittels eines Modulo-Exponentialrechners 224 und eines Modulo-Multiplizierers 222 durch die Verwendung des öffentlichen Schlüssels (eC, nC), der einem verfügbaren begrenzten Geldbetrag A entspricht, welchen der Benutzer 200 zu erhalten wünscht (Nennwertinformation: z. B. 10.000 Yen) und eines Zufallswertes r, der vom Zufallsgenerator 220 erzeugt wird, aus.
  • Figure 00170002
  • Dieses Ergebnis Z wird zusammen mit der Nennwertinformation des elektronischen Geldes, d. h. dem verfügbaren begrenzten Geldbetrag X, an die Bank 100 übertragen.
  • Schritt 2: Die Bank 100 antwortet auf die vom Benutzer 200 empfangene Information Z, um durch die folgende Berechnung unter Verwendung des dem Nennwert des elektronischen Geldes entsprechenden geheimen Schlüssels (dC, nC) und eines Modulo-Exponentialrechners 120, eine provisorische Unterschrift zu erzeugen.
  • Figure 00180001
  • Die provisorische Unterschrift Θ wird an den Benutzer 200 gesendet. Zur selben Zeit zieht die Bank 100 den betreffenden Geldbetrag X vom Konto des Benutzers 200 ab oder empfängt den entsprechenden Geldbetrag vom Benutzer 200 durch irgendein anderes Mittel.
  • Schritt 3: Der Benutzer 200 führt eine Blindunterschriftnachverarbeitung für den öffentlichen Schlüssel (eC, nC) des spezifizierten Geldbetrages und die empfangene Information Θ durch die folgende Gleichung mit einem inversen Modulo-Rechner 212 und einem Modulo-Multiplizierer 223 aus und erhält dadurch das elektronische Geld C mit dem spezifizierten Nennwert. C = Θ/rmodnC (5)
  • Es muss hier beachtet werden, dass C = g(B||I)(modnB).
  • Zahlung mit elektronischem Geld
  • Mit Bezugnahme auf die 4 und 5 wird nun eine Beschreibung der Prozedur gegeben, welcher der Benutzer 200 folgt, um eine Zahlung an das Geschäft 300 mit dem elektronischen Geld c, das von der Bank 100 ausgegeben wurde, zu machen.
  • Schritt 1: Der Benutzer 200 sendet {I, N, B, b, C}, die aus dem Speicher 20M ausgelesen werden, an das Geschäft 300.
  • Schritt 2: Das Geschäft 300 verifiziert durch Überprüfen, ob B die folgende Gleichung erfüllt, die Gültigkeit der Unterschrift B bei (I, N), d. h. die Gültigkeit der Lizenz, durch die Verwendung eines g-Rechners 310a, eines Modulo-Exponentialrechners 310b und eines Vergleichers 310c.
  • Figure 00180002
  • Darüber hinaus verifiziert das Geschäft 300 durch Überprüfen, ob C die folgende Gleichung erfüllt, die Gültigkeit der Unterschrift (B, b) zu dem elektronischen Geld C, d. h. die Gültigkeit des elektronischen Geldes C, durch die Verwendung eines g-Rechners 311a, eines Modulo-Exponentialrechners 311b und eines Vergleichers 311c.
  • Figure 00180003
  • Wenn irgendeine der Unterschriften als ungültig befunden wird, wird keine weitere Verarbeitung mehr fortgesetzt.
  • Schritt 3: Wenn beide Unterschriften als gültig befunden werden, erzeugt das Geschäft 300 einen Zufallswert EV' mittels eines Zufallsgenerators 312, der als ein Nachfrage- oder Abfragegenerator dient, und sendet ihn dann zusammen mit einer Identifikation IDV des Geschäftes 300 und einem Zeitstempel T an den Benutzer 200 und berechnet EV = h(IDV||T||EV') mittels eines h-Rechners 316.
  • Schritt 4: Der Benutzer 200 bestimmt, dass er das elektronische Geld C vom Betrag x zahlt und unterzeichnet den Betrag x und die vom Geschäft 300 empfangene Information durch die folgende Gleichung mittels eines h-Rechners 230, eines g-Rechners 232 und eines Modulo-Exponentialrechners 231. S = g(x||h(IDV||T||EV'))dmodN (8)
  • Die Unterschrift S und der Geldbetrag x werden an das Geschäft 300 als eine Antwort auf dessen Abfrage EV' gesendet.
  • Schritt 5: Basierend darauf, dass der öffentliche Schlüssel (eC, nC) die Überprüfung der Gültigkeit des elektronischen Geldes C bestanden hat, erfasst das Geschäft 300 den maximal zugelassenen Betrag X des elektronischen Geldes C aus einer Wertetabelle, macht dann eine Überprüfung, um zu sehen, ob der Betrag x den zugelassenen Betrag X nicht übertrifft, und wenn dem so ist, hält das Geschäft 300 die nachfolgende Verarbeitung an.
  • Wenn der Betrag x kleiner ist als der zugelassene Betrag X, verifiziert das Geschäft 300 die Gültigkeit der Unterschrift S mittels der folgenden Gleichung durch die Verwendung eines g-Rechners 317, eines Modulo-Exponentialrechners 314 und eines Vergleichers 315. Se ≡ g(x||EV)(modN) (9)
  • Wenn diese Verifikation erfolgreich ist, betrachtet das Geschäft 300 die Zahlung des betreffenden Betrags durch den Benutzer als gültig und nimmt sie entgegen.
  • Abrechnung
  • Unter Hinwendung zu der 6 wird untenstehend nun die Abrechnung zwischen dem Geschäft 300 und der Bank 100 beschrieben. Das Geschäft 300 legt der Bank 100 eine Historie H von Kommunikationen vor, die zwischen dem Geschäft 400 und dem Benutzer 200 ausgetauscht worden sind, als das elektronische Geld C benutzt wurde, d. h., (I, N, B, b, C} vom Benutzer 200, an das Geschäft 300, {IDV, T, EV'} vom Geschäft 300 an den Benutzer 200 und x und S, die vom Benutzer 200 gesendet wurden. Die Bank 100 verifiziert die Gültigkeit der Kommunikationshistorie H; die Bank 100 macht nämlich wie im Fall der Verifikation, die für die Bezahlung mit elektronischem Geld durchgeführt worden ist, die Überprüfungen durch die Gleichungen (6), (7) und (9). Wenn die Lizenz B des Benutzers, das elektronische Geld und die Unterschrift S des Benutzers alle für gültig befunden werden, speichert die Bank 100 die Kommunikationshistorie H und zahlt den betroffenen Geldbetrag x auf das Konto des Geschäfts 300 oder zahlt den Betrag x mittels irgendeines anderen Mittels an das Geschäft 300.
  • Die Bank 100 stellt die Kommunikationshistorie H unter ihre Aufsicht, um zu verhindern, dass das elektronische Geld C über den maximal zugelassenen Betrag X hinaus ausgegeben wird. Z. B. werden nur das elektronische Geld C und der Betrag x in einer ersten Datenbank 10D gespeichert, und es wird Vorsorge getroffen, so dass die erste Datenbank und eine zweite Datenbank 10M, in welcher die Historie der Zahlung H mit dem elektronischen Geld C gespeichert ist, unter Verwendung der Information C als einem Schlüssel abgerufen werden kann. Es kann durch Abrufen der ersten Datenbank 10D überprüft werden, ob der Gesamtbetrag des Geldes, der mit dem elektronischen Geld C gezahlt wurde, den maximal zugelassenen Betrag X übertrifft. Wenn dem so ist (d. h. x > X), wird die Bank 100 die zweite Datenbank 30M abrufen und die Historie der Zahlung H mit dem elektronischen Geld C als Beweis für einen Angriff dem Treuhänder 400 anbieten. Der Treuhänder 400 verwendet die anonyme öffentliche Information, die in der Historie H enthalten ist, um die Entsprechungstabelle 41T nach der Identifikationsinformation IDU des Angreifers zu durchsuchen, wodurch der Treuhänder 400 dessen Identität bestimmen kann.
  • Wenn unabhängig von der Betriebsweise der Bank 100 eine Anordnung oder eine Genehmigung von einem Gericht oder einer ähnlichen offiziellen dritten Partei für die Erfassung eines Angriffs aus der Kommunikationshistorie H gegeben wird, rufen die Bank 100 und der Treuhänder 400 die Identifikationsinformation IDU und den anonymen öffentlichen Schlüssel N des Benutzers, die von der offiziellen dritten Partei spezifiziert wurden, jeweils von der unter die Aufsicht der Bank 100 gestellten Kommunikationshistorie H und der Entsprechungstabelle 41T, die beim Treuhänder 400 verwahrt ist, ab, und bieten die Teile der so aufgefundenen Information der offiziellen dritten Partei an.
  • Teilweises Übertragen von elektronischem Geld
  • Mit Bezug auf die 7, 8 und 9 wird eine Beschreibung des Falles gegeben, in dem der Benutzer 200 das von der Bank 100 ausgegebene elektronische Geld C teilt und den geteilten Geldbetrag an einen anderen Benutzer 500 überträgt. Es wird hier angenommen, dass ein Suffix „1" an jedes derjenigen Symbole angehängt wird, welche Schlüssel und Teile von anderer Information des ersten Benutzers (200) repräsentieren, und ein Suffix „2" an jedes derjenigen Symbole angehängt wird, welche Schlüssel und Teile von anderer Information des zweiten Benutzers (500) repräsentieren. Es sei die Lizenz des Benutzers 200 durch (B1, I1, N1) repräsentiert, das elektronische Geld durch (C, b) und die Lizenz des Benutzers 500 durch (B2, I2, N2). Die in 8 gezeigte funktionale Konfiguration des Benutzers 500 ist praktisch identisch mit der funktionalen Konfiguration des Benutzers 300 in 5.
  • Schritt 1: Der Benutzer 200 überträgt die Lizenz (B1, I1, N1) und das elektronische Geld (b, C) an den Benutzer 500.
  • Schritt 2: Der Benutzer 500 verifiziert die Gültigkeit der Unterschrift B1 zu (I1, N1) (d. h. die Gültigkeit der Lizenz) durch Überprüfen, ob B1 die folgende Gleichung erfüllt, unter Verwendung eines g-Rechners 510a, eines Modulo-Exponentialrechners 510b und eines Vergleichers 510c.
  • Figure 00210001
  • Darüber hinaus wird die Gültigkeit der Unterschrift C zu (B1, b) (d. h. die Gültigkeit des elektronischen Geldes) durch Überprüfen verifiziert, ob C die folgende Gleichung erfüllt, unter der Verwendung eines g-Rechners 511a, eines Modulo-Exponentialrechners 511b und eines Vergleichers 511c.
  • Figure 00210002
  • Wenn irgendeine der Unterschriften B1 und C als ungültig befunden wird, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt 3: Wenn die beiden Unterschriften B1 und C als gültig befunden werden, erzeugt der Benutzer 500 einen Zufallswert E2' mittels eines Zufallsgenerators 512, der als Nachfrage- oder Abfragegenerator dient, und sendet ihn dann zusammen mit einer Unterschrift B2 des Benutzers 500 und einem Zeitstempel T an den Benutzer 200 und berechnet E2 =h(B2||T||E2') mittels eines h-Rechners 516.
  • Schritt 4: Der Benutzer 200 bestimmt, dass er einen gewissen Geldbetrag x vom Nennwert des elektronischen Geldes C teilt, und ihn an den Benutzer 500 überträgt, und erzeugt die folgende Unterschrift mittels des h-Rechners 230, des g-Rechners 232 und des Modulo-Exponentialrechners 231.
  • Figure 00210003
  • Die Unterschrift S1 und der Geldbetrag x werden an den Benutzer 500 als eine Antwort auf dessen Anfrage gesendet.
  • Schritt 5: Anhand des öffentlichen Schlüssels (eC, nC), der die Überprüfung der Gültigkeit des elektronischen Geldes C bestanden hat, erfasst der Benutzer 500 den für das elektronische Geld C zugelassenen maximal verfügbaren Betrag X aus einer Wertetabelle 518, vergleicht dann dessen Wert A und den Betrag x mittels eines Vergleichers 519, um zu sehen, ob der letztere den ersteren nicht übertrifft, und wenn dem so ist, hält der Benutzer 500 die nachfolgende Verarbeitung an.
  • Wenn der Betrag x kleiner ist als der zugelassene Betrag X, verifiziert der Benutzer 500 die Gültigkeit der Unterschrift S1 durch die folgende Gleichung durch die Verwendung eines g-Rechners 517, eines Modulo-Exponentialrechners 514 und eines Vergleichers 515.
  • Figure 00210004
  • Wenn diese Verifikation erfolgreich ist, betrachtet der Benutzer 500 die Übertragung des Betrages x des Benutzers als gültig und nimmt sie dementsprechend entgegen.
  • Zahlung mit geteiltem, übertragenem elektronischem Geld
  • Mit Bezug auf die 9 und 5 wird eine Beschreibung der Prozedur für den Benutzer 500 gegeben, um die Zahlung an das Geschäft 300 mit dem vom Benutzer 200 übertragenen elektronischen Geld zu machen.
  • Schritt 1: Der Benutzer 500 liest aus einem Speicher 50M die Lizenz (B2, I2, N2) und eine Historie der Kommunikationen H1 (I1, N1, B1, b, C, x, T, E2', S1) aus, die mit dem Benutzer 200 zur Übertragung des elektronischen Geldes von dort durchgeführt worden sind, wobei die Lizenz und die Kommunikationshistorie an das Geschäft 300 gesendet werden.
  • Schritt 2: Das Geschäft 300 verifiziert die Gültigkeit der Unterschrift B2 zu (I2, N2) (d. h. die Gültigkeit der Lizenz) durch Überprüfen, ob B2 die folgende Gleichung erfüllt, unter der Verwendung des g-Rechners 310a, des Modulo-Exponentialrechners 310b und des Vergleichers 310c.
  • Figure 00220001
  • Darüber hinaus verifiziert das Geschäft 300 auch die Gültigkeit der Kommunikationshistorie H1 (genauso wie die Überprüfung der Gültigkeit der Übertragung von elektronischem Geld und der Zahlung mittels elektronischem Geld).
  • Wenn diese Überprüfungen nicht bestanden werden, wird keine weitere Verarbeitung mehr fortgesetzt.
  • Schritt 3: Wenn diese Überprüfungen bestanden werden, erzeugt das Geschäft 300 einen Zufallswert EV' mittels des Zufallsgenerators 312, sendet ihn dann zusammen mit der Kennung IDV des Geschäftes 300 und einem Zeitstempel T' an den Benutzer 500 und berechnet EV = h(IGV||T'||EV' mittels des h-Rechners 316.
  • Schritt 4: Der Benutzer 500 bestimmt, dass er einen Betrag y des übertragenen Betrags x ausgibt, und erzeugt eine Unterschrift nach der folgenden Gleichung mit einem h-Rechner 530, einem g-Rechner 532 und einem Modulo-Exponentialrechner 531.
  • Figure 00220002
  • Die Unterschrift S2 und der Betrag y werden an das Geschäft 300 gesendet.
  • Schritt 5: Das Geschäft 300 vergleicht den übertragenen Betrag x in der Kommunikationshistorie H1, die es vom Benutzer 500 empfangen hat, mit dem Betrag y mittels dem Vergleicher 319, um zu sehen, ob der Betrag y kleiner ist als der übertragene Betrag x des elektronischen Geldes C. Wenn diese Überprüfung nicht bestanden wird, hält das Geschäft 300 die nachfolgende Verarbeitung an.
  • Wenn diese Überprüfung bestanden wird, verifiziert das Geschäft 300 die Gültigkeit der Unterschrift S2 durch die folgende Gleichung durch die Verwendung des g-Rechners 317, des Modulo-Exponentialrechners 314 und des Vergleichers 315.
  • Figure 00230001
  • Wenn diese Verifizierung erfolgreich ist, betrachtet das Geschäft 300 die Zahlung des Betrag y durch den Benutzer als gültig und nimmt diese an.
  • Wie oben beschrieben, vergleicht diejenige Seite, die einen abgeteilten Teil des elektronischen Geldes empfängt, wenn es verwendet wird (gezahlt oder übertragen), nur dessen Betrag mit dem zugelassenen maximalen Betrag an elektronischem Geld, es könnte aber ein Angriff erkannt werden, indem man die Historie des elektronischen Geldes unter die Aufsicht durch die Bank stellt.
  • Bei der ersten Ausführung wurde beschrieben, dass die Entsprechung zwischen der Benutzeridentifikationsinformation IDU und der anonymen öffentlichen Information N von einem Treuhänder 400 unterhalten wird. Der Treuhänder 400 kann ebenfalls in eine Mehrzahl von Abteilungen aufgeteilt sein, so dass der Name des Benutzers nur dann mit dieser anonymen öffentlichen Information verbunden werden kann, wenn die Abteilungen miteinander kooperieren. Wenn darüber hinaus ein Angriff auf das System festgestellt wird, muss die Bank 100 den Treuhänder 400 nur mit der vollen anonymen öffentlichen Information N versorgen, die mit dem entsprechenden elektronischen Geld C in Beziehung steht; die volle Historie H muss nicht immer gesendet werden.
  • Zweite Ausführung
  • Die erste Ausführung wurde so beschrieben, dass sie die RSA-Digitalunterschrift- und Blindunterschriftschemata einsetzt, wie aber zuvor beschrieben wurde, kann die vorliegende Erfindung realisiert werden, indem man ein willkürliches digitales Unterschriftschema und ein Unterschriftschema verwendet, das zu Blindunterschriften in der Lage ist, die im System vorbestimmt sind, z. B. in der Unterschriftgleichung (2) des Schrittes 4 bei der Prozedur für die Ausgabe der Lizenz (2), in den Blindunterschriftgleichungen (3), (4) und (5), bei der Prozedur zur Ausgabe von elektronischem Geld (3), bei der Unterschriftgleichung (8) des Benutzers in Schritt 4 der Prozedur für die Zahlung von elektronischem Geld an das Geschäft (4 und 5), in der Benutzerunterschriftgleichung (12) des Schrittes 4 der Prozedur für die Übertragung von elektronischem Geld (7 und 8), oder in der Benutzerunterschriftgleichung (15) des Schrittes 4 der Prozedur für die Verwendung des übertragenen elektronischen Geldes (9 und 5).
  • Bei der zweiten Ausführung verwendet der Treuhänder 400 das digitale „RSA"-Unterschriftschema für den Benutzer 200, die Bank 100 das auf dem interaktiven Beweis mit Null-Wissen basierende Blindunterschriftschema durch das „OO"-Schema für den Benutzer 200, und der Benutzer 200 das digitale „ESIGN"-Unterschriftschema für das Geschäft 300.
  • 10 stellt die Prozedur für den Benutzer 200 dar, um den Treuhänder 400 zur Ausgabe der Lizenz zu veranlassen.
  • Schritt S1: Der Benutzer 200 erzeugt zwei große Primzahlen P und Q, erzeugt dann eine zusammengesetzte Zahl N (N =p2 × Q) als einen öffentlichen anonymen Schlüssel N durch Multiplikation, der in einem Speicher gespeichert und an den Treuhänder 400 übertragen wird.
  • Schritt S2: Der Treuhänder 400 überprüft auf irgendeine Weise die Identität des Benutzers 200 und hält, wenn die Überprüfung bestanden wird, die Entsprechung zwischen dem Benutzer 200 und dem öffentlichen anonymen Schlüssel N durch die Verwendung einer Entsprechungstabelle geheim, und erzeugt dann Information I wie z. B. die Dauer der Gültigkeit.
  • Schritt S3: Darüber hinaus berechnet der Treuhänder 400 eine digitale Unterschrift der folgenden Gleichung mittels der Hash-Funktion g und Modulo-Exponentialberechnung durch Verwendung eines Geheimschlüssels (dB, nB) für die Unterschrift des Treuhänders 400 und sendet die digitale Unterschrift B und die Information I an den Benutzer 200.
  • Figure 00240001
  • Schritt S4: Der Benutzer 200 speichert die von dem Treuhänder 400 empfangenen Daten (B, I) und den Satz von öffentlichen Schlüsseln N (B, I, N), die im Schritt S1 erzeugt wurden, als eine Lizenz in dem Speicher (Ausgabe der Lizenz).
  • 11 zeigt die Prozedur für den Benutzer 200, um von der Bank 100 elektronisches Geld ausgegeben zu bekommen.
  • Schritt S5: Als Antwort auf eine Anfrage des Benutzers 200 zur Ausgabe von elektronischem Geld erzeugt die Bank 100 einen Zufallswert r, berechnet dann
    Figure 00240002
    mittels der Modulo-Exponentialberechnung und überträgt es an den Benutzer 200.
  • Schritt S6: Der Benutzer 200 erzeugt Zufallswerte r' und b, berechnet dann
    Figure 00240003
    durch Berechnen der Hash-Funktion g und speichert es in dem Speicher und berechnet c = g(B||a)modnC durch Berechnen der Hash-Funktion g und speichert es in dem Speicher; darüber hinaus führt der Benutzer 200 eine Blindunterschriftvorverarbeitung c' = c + bmodLC mittels Addition, Subtraktion und Modulo-Berechnung aus und überträgt sie an die Bank 100.
  • Schritt S7: Die Bank 100 verwendet den dem Nennwert des elektronischen Geldes entsprechenden öffentlichen Schlüssel (hC, LC, nC) und einen Geheimschlüssel xC, um eine Blindunterschrift y' = rxc cmodnC mittels Modulo-Exponentialberechnung und Modulo-Multiplikation zu berechnen, und überträgt sie an den Benutzer 200. Zur selben Zeit zieht die Bank 100 den betreffenden Betrag vom Konto des Benutzers ab oder empfängt den Betrag durch irgendein anderes Mittel vom Benutzer 200.
  • Schritt S8: Der Benutzer 200 berechnet mittels Addition, Subtraktion und Modulo-Berechnung d, welches c' = c + b + dLerfüllt, und führt die Blindunterschriftnachverarbeitung y = y'r'h–dmodnC mittels Modulo-Exponentialberechnung und Modulo-Multiplikation aus und speichert a und c als das elektronische Geld C = {a, c, y} in dem Speicher (Abheben von elektronischem Geld).
  • 12 zeigt die Prozedur für den Benutzer 200, um Zahlungen an das Geschäft 300 mittels elektronischem Geld C zu machen, die Prozedur für die nachfolgende Abrechnung zwischen dem Geschäft 300 und der Bank 100, und die Darlegung von Information von der Bank 100 an den Treuhänder 400.
  • Schritt S1: Der Benutzer 200 sendet I, N, B, C an das Geschäft 300.
  • Schritt S2: Das Geschäft 300 verifiziert die Gültigkeit der Unterschrift B zu (I, N) durch Überprüfen, ob die Unterschrift B die folgende Gleichung erfüllt (Überprüfen der Gültigkeit der Lizenz)
    Figure 00250001
    durch Berechnen der Hash-Funktion g, Modulo-Exponentialberechnung und einem Vergleich durch Verwendung des öffentlichen Schlüssels (eB, nB) für die Unterschrift des Treuhänders 400 und das Geschäft 300 verifiziert die Gültigkeit des elektronischen Geldes C = {a, c, y} zu der Unterschrift B durch Überprüfen, ob die Unterschrift B die folgende Gleichung erfüllt (Überprüfen der Gültigkeit des elektronischen Geldes)
    Figure 00260001
    c = g(B||a)durch Modulo-Exponentialberechnung und Vergleich durch Verwendung des öffentlichen Schlüssels (hC, LC, nC) der Bank 100. Wenn diese Überprüfungen nicht bestanden werden, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt S4: Wenn diese Überprüfungen bestanden werden, erzeugt das Geschäft 300 den Zufallswert E' und sendet ihn zusammen mit der Identifikation IDV des Geschäftes 300 und dem Zeitstempel T an den Benutzer 200.
  • Schritt 5: Darüber hinaus berechnet das Geschäft 300 durch Berechnen der Hash-Funktion h die folgende Gleichung. E = h(IDV||T||E')
  • Schritt S6: Der Benutzer 200 bestimmt, dass er das elektronische Geld c vom Betrag x ausgibt, und berechnet m = x||h(IDV||T||E')mittels der Hash-Funktion h.
  • Schritt S7: Darüber hinaus verwendet der Benutzer 200 den geheimen Schlüssel (p, q), um eine ESIGN-Unterschrift S durch die folgende Gleichung zu erzeugen S = ESIG(m, p, q)und sendet den Betrag x und die Unterschrift S an das Geschäft 300.
  • Schritt S8: Das Geschäft 300 macht eine Überprüfung, ob der Betrag x den zugelassenen maximalen Betrag X des elektronischen Geldes C nicht übersteigt, und wenn diese Überprüfung nicht bestanden wird, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt S9: Wenn die Überprüfung bestanden wird, verwendet das Geschäft 300 m, S und N, um die Gültigkeit der ESIGN-Unterschrift S durch die folgende Gleichung zu überprüfen EVER(m, S, N) = OK/NG
  • Wenn diese Überprüfung bestanden wird, sieht das Geschäft 300 die Zahlung des diesem x entsprechenden Betrages durch den Benutzer 200 als gültig an und nimmt sie an (Zahlung mittels elektronischem Geld) und versorgt die Bank 100 mit der Historie H der Kommunikationen, die zwischen dem Geschäft 300 und dem Benutzer 200 durchgeführt worden sind, als das elektronische Geld ausgegeben wurde.
  • Schritt S10: Die Bank 100 überprüft die Gültigkeit der Kommunikationshistorie H und speichert, wenn die Überprüfung bestanden wird, die Historie H und zahlt den betreffenden Betrag auf das Konto des Geschäfts 300, oder zahlt den Betrag mittels irgendeines anderen Mittels an das Geschäft 300 (Konvertierung von elektronischem Geld).
  • Schritt S11: Darüber hinaus setzt die Bank 100 die Historie H unter ihre Aufsicht, um zu verhindern, dass das elektronische Geld c über den zugelassenen maximalen Betrag hinaus ausgegeben wird (Überwachung von elektronischem Geld). Wenn das elektronische Geld c über den maximalen Betrag hinaus ausgegeben wird, legt die Bank 100 die Historie H von allen Zahlungen, die mit dem elektronischen Geld C gemacht wurden, als Beweis für einen Missbrauch offen.
  • Schritt S12: Der Treuhänder 400 extrahiert die öffentliche Information N aus der Historie H und sucht die Entsprechungstabelle der Identifikationsinformation IDU und die öffentliche Information N nach bestimmter Benutzeridentifikationsinformation IDU ab, um den Angreifer zu spezifizieren (Erfassung des Angreifers).
  • 13 zeigt die Prozedur für den Benutzer 200, um das elektronische Geld C zu teilen und an einen anderen Benutzer 500 zu übertragen.
  • Schritt S1: Der Benutzer 200 sendet die Lizenz (B1, I1, N1) und das elektronische Geld C = {a, c, y} an den Benutzer 500.
  • Schritt S2: Der Benutzer 500 verifiziert die Gültigkeit der Unterschrift B1 zu (I1, N1) durch Überprüfen, ob sie die folgende Gleichung erfüllt (Überprüfen der Gültigkeit der Lizenz)
    Figure 00270001
    durch Berechnen der Hash-Funktion g, Modulo-Exponentialberechnung und Vergleich.
  • Schritt S3: Darüber hinaus verifiziert das Geschäft 300 die Gültigkeit des elektronischen Geldes C = {a, c, y} zu der Unterschrift B1 durch Überprüfen, ob die folgende Gleichung erfüllt ist (Überprüfung der Gültigkeit des elektronischen Geldes) durch Modulo-Exponentialberechnung und Vergleich unter Verwendung des öffentlichen Schlüssels (hC, LC, nC) der Bank 100,
    Figure 00270002
    c = g(B1||a)
  • Wenn diese Überprüfung nicht bestanden wird, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt S4: Wenn diese Überprüfung bestanden wird, erzeugt der Benutzer 500 den Zufallswert E' und sendet ihn zusammen mit der Unterschrift B2 und dem Zeitstempel T an den Benutzer 500.
  • Schritt S5: Darüber hinaus berechnet der Benutzer 500 die folgende Gleichung durch Berechnen der Hash-Funktion h. E = h(B2||T||E')
  • Schritt S6: Der Benutzer 200 bestimmt, dass er das elektronische Geld C vom Betrag x überträgt, und berechnet m = x||h(B2||T||E')mittels der Hash-Funktion h.
  • Schritt S7: Darüber hinaus verwendet der Benutzer 200 seinen geheimen Schlüssel (p, q) und m, um eine ESIGN-Unterschrift S, mittels der folgenden Gleichung zu erzeugen S1 = ESIG(m, p. q)und sendet den Betrag x und die Unterschrift S1 an den Benutzer 500.
  • Schritt S8: Der Benutzer 500 macht eine Überprüfung, ob der Betrag x den zugelassenen maximalen Betrag X des elektronischen Geldes C nicht übersteigt, und wenn diese Überprüfung nicht bestanden wird, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt S9: Wenn die Überprüfung bestanden wird, verwendet der Benutzer 500 m, S und N, um die Gültigkeit der ESIGN-Unterschrift S durch die folgende Gleichung zu überprüfen EVER(m, S, N) = OK/NG
  • Wenn diese Überprüfung bestanden wird, sieht der Benutzer 500 die Übertragung des diesem x entsprechenden Betrages durch den Benutzer 200 als gültig an und nimmt sie an (Übertragung von elektronischem Geld).
  • 14 zeigt die Prozedur für die Zahlung mit dem geteilten, übertragenen elektronischen Geld an das Geschäft.
  • Schritt S1: Der Benutzer 500 sendet die Lizenz (B2, I2, N2) und eine Historie H1 (I1, N1, B1, b, C, x, T, E', S1) der Kommunikationen, die mit dem Benutzer 200 durchgeführt wurden, um von ihm das elektronische Geld zu übertragen, an das Geschäft 300.
  • Schritt S2: Das Geschäft 300 verifiziert die Gültigkeit der Unterschrift B2 zu (I2, N2) durch Überprüfung, ob sie die folgende Gleichung erfüllt (Überprüfung der Gültigkeit der Lizenz) durch Berechnen der Hash-Funktion g, Modulo-Exponentialberechnung und Vergleich.
  • Figure 00290001
  • Darüber hinaus verifiziert das Geschäft 300 ebenso die Gültigkeit der Kommunikationshistorie H1. Falls diese Überprüfung nicht bestanden wird, wird keine weitere Verarbeitung fortgeführt.
  • Schritt S3: Wenn diese Überprüfung bestanden wird, erzeugt das Geschäft 300 den Zufallswert EV' und sendet ihn zusammen mit der Identifikationsinformation IDV des Geschäfts 300 und einem Zeitstempel T' an den Benutzer 500.
  • Schritt S4: Der Benutzer 500 berechnet EV = h(IDV||T'||EV')durch Berechnen der Hash-Funktion h.
  • Schritt S5: Der Benutzer 200 bestimmt, dass er einen Betrag y des Betrages x ausgeben will und berechnet m = x||h(IDV||T'||E')mittels der Hash-Funktion h.
  • Schritt S6: Darüber hinaus verwendet der Benutzer 500 seinen geheimen Schlüssel (p, q) und m, um eine ESIGN-Unterschrift S2 mittels der folgenden Gleichung zu erzeugen S2 = ESIG(m, p, q)und sendet den Betrag y und die Unterschrift S2 an das Geschäft 300.
  • Schritt S7: Das Geschäft 300 macht eine Überprüfung, ob der Betrag y den übertragenen Betrag x des elektronischen Geldes C nicht übersteigt, und wenn diese Überprüfung nicht bestanden wird, wird keine weitere Verarbeitung mehr ausgeführt.
  • Schritt S8: Wenn diese Überprüfung bestanden wird, verwendet das Geschäft 300 m, S und N, um die Gültigkeit der ESIGN-Unterschrift S2 mittels der folgenden Gleichung zu überprüfen EVER(m, S2, N2) = OK/NG
  • Wenn diese Überprüfung bestanden wird, sieht das Geschäft 300 die Zahlung des Betrags y durch den Benutzer 200 als gültig an und nimmt sie an (Zahlung mittels elektronischem Geld) und versorgt die Bank 100 mit einer Historie H2 von allen Kommunikationen.
  • Schritt S9: Die Bank 100 überprüft die Gültigkeit der Kommunikationshistorie H2.
  • Schritt S10: Die Bank 100 macht eine Überprüfung, ob der Betrag y kleiner ist als der Kontostand x, und falls nicht, sendet sie die Kommunikationshistorie H2 an den Treuhänder 400.
  • Schritt S11: Der Treuhänder 400 extrahiert die öffentliche Information N oder N2 aus der Historie H2 und sucht die Entsprechungstabelle nach bestimmter Benutzeridentifikationsinformation IDU oder IDU2 ab.
  • Schritt S12: Wenn unabhängig vom Betrieb der Bank 100 eine Anweisung oder Autorisierung von einem Gericht oder einer ähnlichen offiziellen dritten Partei zur Erfassung eines Angriffs aus der Kommunikationshistorie H gegeben wird, gewinnen die Bank 100 und der Treuhänder 400 die Identifikationsinformation IDU und den anonymen öffentlichen Schlüssel N des Benutzers, der durch die offizielle dritte Partei spezifiziert wurde, aus der unter die Aufsicht der Bank 100 gestellten Kommunikationshistorie H und der Entsprechungstabelle 41T, die vom Treuhänder 400 unterhalten wird, jeweils wieder, und sie bieten die auf diese Weise herausgefundenen Teile der Information der offiziellen dritten Partei an.
  • Dritte Ausführung
  • Während im Obigen die Lizenz derart beschrieben wurde, dass sie z. B. wie in 1 gezeigt, von einem Treuhänder ausgegeben wird, kann die Lizenz genauso unter der Aufsicht einer Mehrzahl von Treuhändern, wie zuvor hingewiesen wurde, ausgegeben werden. Mit einer solchen Anordnung kann der Benutzer, der die Lizenz besitzt, nicht von einem Treuhänder alleine spezifiziert werden, sondern der Benutzer, der die Lizenz oder das elektronische Geld besitzt, könnte z. B. mit der Kooperation von allen Treuhändern unter der Autorisierung durch ein Gericht spezifiziert werden. Eine Ausführung dieses Schemas wird unten stehend unter Bezugnahme auf die 15 bis 18 beschrieben.
  • 15 ist ein Blockdiagramm, das eine grundlegende Konfiguration dieser Ausführung darstellt. Eine Mehrzahl von Treuhändern 40T1 bis 40Tt , der Benutzer 200 und ein Gericht 600 sind beispielsweise über Kommunikationsleitungen untereinander verbunden, sie können aber auch mittels einer Chipkarte oder etwas ähnlichem, auf dem Information aufgezeichnet werden kann, untereinander verbunden sein. Das Unterschriftensystem und öffentliche Schlüsselkryptographie, die in dieser Ausführung verwendet werden, basieren auf dem RSA-Schema, und diese Ausführung kann durch eine beliebige Einwegfunktion g, ein digitales Unterschriftensystem und ein Kryptosystem mit öffentlichem Schlüssel implementiert sein.
  • Vorab-Prozedur
  • g ist als eine öffentliche Einwegfunktion gesetzt und (ε, δ) sind im Voraus als ein Geheimschlüsselkryptosystem veröffentlicht, um die Prozedur zu veröffentlichen. Die diese berechnenden Vorrichtungen werden im Folgenden ein g-Rechner, ein ε-Verschlüssler und ein δ-Entschlüssler genannt. Bei dieser Ausführung sind der Unterschriftenalgorithmus und der öffentliche Schlüsselverschlüsselungsalgorithmus, die der Treuhänder 40Ti verwendet, vom RSA-Schema. Diese Algorithmen verwenden den Geheimschlüssel und den öffentlichen Schlüssel (dTi, nTi) und (eTi, nTi), um die Verschlüsselungsverarbeitungsfunktion Ei(x) und eine Entschlüsselungsverarbeitungsfunktion Di(y), die durch jeweils die folgenden Gleichungen gegeben sind, zu berechnen.
  • Figure 00310001
  • Prozedur zum Ausgeben der Lizenz
  • Der Benutzer 200 registriert die zusammengesetzte Zahl N bei dem Treuhänder 40T1 , und es wird ihm als eine Lizenz B für elektronisches Geld eine unterschriebene Quittung ausgegeben, indem eine digitale Unterschrift an die Information N angehängt wird. Der Vorgang dafür ist wie unten stehend mit Bezugnahme auf die 16, 17 und 18 beschrieben.
  • Schritt 1: Der Benutzer 200 erzeugt mittels eines Schlüsselgenerators 201 Schlüssel (k1, ... kt) in einer der Zahl der Treuhänder 40T1 entsprechenden Zahl (16). Der Benutzer 200 verwendet den öffentlichen Schlüssel (eTi, nTi) des Treuhänders 40Ti , um rekursiv ϕi = Ei(ki||ϕi–1) mittels öffentlicher Schlüsselverschlüsseler 2021 bis 202t zu berechnen, wodurch er ϕt erhält.
  • Nebenbei bemerkt sei ϕ0 die Identifikationsinformation IDU des Benutzers 200. Außerdem berechnet der Benutzer 200 mittels eines Multiplizierers 211 das Produkt N großer Primzahlen, die von einem Primzahlgenerator 210 erzeugt werden, berechnet dann rekursivΦ1 = E1o ... oEt(N||ϕt)mittels eines öffentlichen Schlüsselverschlüsselers 2021 bis 2031 durch Verwendung des öffentlichen Schlüssels (eTi, nTi) des Treuhänders 40Ti und überträgt ϕ1 als Information, die N und IDV enthält, an den Treuhänder 40T 1. EioEj(x) bedeutet hier Ei(Ej(x)).
  • Schritt 2: Der Treuhänder 40T1 verwendet den Geheimschlüssel (dTi, nTi) um Φ2 = D1(Φ1) mittels eines öffentlichen Schlüsselentschlüsslers 4011 zu berechnen (17), was an den Treuhänder 40T2 gesendet wird.
  • Schritt 3: Jeder Treuhänder 40Ti verwendet den Geheimschlüssel (dTi, nTi), um Φi+1 = Di(Φi) mittels des öffentlichen Schlüsselentschlüsslers 401; zu berechnen, und überträgt es an den nächsten Treuhänder 40Ti+1 , so dass der Treuhänder 40Tt schließlich ϕt erhält.
  • Schritt 4: Der Treuhänder 40Tt verwendet den Geheimschlüssel (dTt, nTt), um (N||Φt) = Dt(Φt) und (kt||ϕt–1) = Dt(ϕt) mittels des öffentlichen Schlüsselentschlüsslers 401t zu erhalten. Nachdem N, ϕt–1, kt erhalten worden sind, berechnet der Treuhänder 40Tt mittels eines g-Rechners 412 g(N) und verwendet den Geheimschlüssel (dT, nT) um die folgende digitale Unterschrift für N mittels eines digitalen Unterschriftengenerators 413 zu erzeugen.
  • Figure 00320001
  • Die vom Entschlüsseler 402t entschlüsselte Information kT ist ein Schlüssel, der vom Benutzer dem Treuhänder 40Tt zugewiesen wird. Der Treuhänder 40Tt verwendet die Information kT als einen Geheimschlüssel, um die Unterschrift B mittels eines ε-Verschlüsselers 405t zu ΨT = Εkt(B) zu verschlüsseln, überträgt dann (ϕt–1, Ψt) an den unmittelbar vorhergehenden Treuhänder Tt–1 und speichert die Information N, B, Ψt im Speicher 40Mt .
  • Schritt 5: Der Treuhänder 40Ti verwendet den Geheimschlüssel (dTi, nTi), um (ki||ϕi–1) = Di(ϕi) mittels eines öffentlichen Schlüsselentschlüsselers 4021 zu berechnen, und verwendet ki als einen Geheimschlüssel, um Ψi = εki(Ψi+1) mittels eines ε-Verschlüsselers 405i zu berechnen. (ϕi–1, Ψi) wird an den unmittelbar vorhergehenden Treuhänder 40Ti–1 , übermittelt, während zur selben Zeit Ψi und Ψi+1 im Speicher 40Mi gespeichert werden. Indem dies wiederholt wird, erhält der Treuhänder 40T2 schließlich jeweils ϕ1 und Ψ2 vom öffentlichen Schlüsselverschlüsseler 4022 und dem Verschlüsseler 4052 .
  • Schritt 6: Der Treuhänder 40T 1 verwendet den Geheimschlüssel (dT1, nT1), um (k1||IDU) = D1(ϕ1) mittels des öffentlichen Schlüsselentschlüsselers 4021 zu berechnen, und spezifiziert den Benutzer 200 durch die dadurch erhaltene Identifikationsinformation IDU. Darüber hinaus verwendet der Treuhänder 40T1 k1, um Ψ1 = εk1(Ψ2) mittels dem ε-Verschlüsseler 4051 zu berechnen, wobei der Treuhänder 40T1 anschließend Ψ1 an den Benutzer 200 überträgt und Ψ1 und Ψ2 in dem Speicher 40M1 in Entsprechung mit der Identifikationsinformation IDU speichert.
  • Schritt 7: Der Benutzer 200 verwendet die Schlüssel (k1, ... kt), um von den Entschlüsselern 204 bis 204t eine Empfangsbestätigung wie die folgende Lizenz B zu erhalten. B = δkto ... oδk1(Ψ1) = (N)dTmodnT
  • Durch die oben beschriebene Verarbeitung speichern der Treuhänder 40T1 , der Treuhänder 40Tt und die anderen Treuhänder 40Ti jeweils die Entsprechung der Information IDU, Ψ2 und Ψ1, die Entsprechung der Information N, B und Ψ1, und die Entsprechung der Information Ψi+1, und Ψi als registrierte Information in ihren Speichern 40M1 , 40Mt und 40Mi und halten sie geheim. Andererseits kann der Benutzer 200 das elektronische Geld C, das zuvor in der ersten und zweiten Ausführung beschrieben wurde, das von der Bank 100 durch Verwendung der Lizenz B, die vom Benutzer 200 gegeben wurde, ausgegeben wird, bekommen und kann das elektronische Geld C im Geschäft 300 ausgeben. Nebenbei bemerkt wird die in dieser Ausführung vom Benutzer 200 empfangene Information N als sein Pseudonym I verwendet, und die Entsprechung zwischen der Pseudonym-Information N und dem realen Namen des Benutzers (Identifikationsinformation IDU) wird von allen Treuhändern 40T1 bis 40Tt durch das Medium der Information Ψi beibehalten. Auf diese Weise kann das Pseudonym I vom Treuhänder in Entsprechung mit der Benutzeridentifikationsinformation IDU frei bestimmt werden. Dies gilt für die erste und die zweite Ausführung.
  • Identifikation des Benutzers von registrierter Information und umgekehrt
  • Benutzerform (N, B)
  • Das Folgende ist die Prozedur, durch welche die Treuhänder 40T1 bis 40Tt den Benutzer 200 aus der Information (N, B) durch die Verwendung der Speicher 40M1 bis 40Mt auf Anfrage einer vertrauenswürdigen dritten Partei (z. B. eines Gerichts) herausfinden (siehe 18).
  • Schritt 1: Die vertrauenswürdige dritte Partei (z. B. ein Gericht) überträgt die Information (N, B) an den Treuhänder 40Tt .
  • Schritt 2: Der Treuhänder 40Tt verwendet die Lizenz B, um Information (N, B, Ψt) aus dem Speicher 40Mt abzurufen und überträgt Ψt an den unmittelbar vorhergehenden Treuhänder 40Tt–1 .
  • Schritt 3: Der Treuhänder 40Ti verwendet Ψi+1, um Information (Ψi+1, Ψi) aus dem Speicher 40Mi abzurufen und überträgt Ψi an den unmittelbar vorhergehenden Treuhänder 40Ti–1 (wobei i = t – 1, t – 2, ..., 3, 2).
  • Schritt 4: Der Treuhänder 40T1 verwendet Ψ2, um Information (IDU, Ψ2, Ψ1) aus dem Speicher 40M1 abzurufen, spezifiziert dann den Benutzer 200 mittels der Information IDU und informiert die vertrauenswürdige dritte Partei (z. B. ein Gericht) über den identifizierten Benutzer 200.
  • (N, B) vom Benutzer
  • Das Folgende ist die Prozedur, durch welche die Treuhänder 40T1 bis 40Tt die Zahlungshistorie H eines Angreifers U durch die Verwendung der Speicher 40M1 bis 40Mt auf eine Anfrage von einer vertrauenswürdigen dritten Partei (z. B. einem Gericht) herausfinden (siehe 19).
  • Schritt 1: Die vertrauenswürdige dritte Partei (z. B. ein Gericht) übermittelt eine Identifikationsinformation IDU des Angreifers an den Treuhänder 40T1 .
  • Schritt 2: Der Treuhänder 40T1 verwendet die Identifikationsinformation IDU, um Information (IDV, Ψ2, Ψ1) aus dem Speicher 40M1 abzurufen, und überträgt Ψ2 an den nächsten Treuhänder 40T2 .
  • Schritt 3: Der Treuhänder 40Ti verwendet Ψi, um Information (Ψi+1, Ψi) aus dem Speicher 40Mi abzurufen, und überträgt Ψi+1 an den nächsten Treuhänder 40Ti+1 (wobei i = 2, 3, ..., t – 1).
  • Schritt 4: Der Treuhänder 40Tt verwendet Ψt, um Information (N, B, Ψt, kt) aus dem Speicher 40Mt abzurufen, spezifiziert dann die Lizenz B und informiert die vertrauenswürdige dritte Partei (z. B. ein Gericht) über die spezifizierte Lizenz B.
  • Nebenbei sei erwähnt, dass es in 17 auch möglich ist, eine Konfiguration einzusetzen, in welcher jeder Treuhänder 40Ti (wobei i = 2, 3, ..., t – 1) ein Paar ϕ1 und ϕi–1 in dem Speicher 40Mi speichert, anstatt das Paar Ψi+1 und Ψi zu speichern, der Treuhänder 40Tt ein Paar ϕt und ϕt–1 in dem Speicher 40Mt speichert, anstatt Ψt zu speichern und der Treuhänder 40T1 ϕ1 im Speicher 40M1 speichert anstatt das Paar mit Ψ2 und Ψ1 zu speichern. Auch in einem solchen Fall ist es möglich, die Benutzeridentifikationsinformation IDU auf der Basis der Informationen (N, B) und umgekehrt zu verfolgen.
  • Wie oben beschrieben, kann gemäß der dritten Ausführung die Beziehung zwischen dem Benutzer 200 und der Information (N, B) geheim gehalten werden, bis alle Treuhänder 40T1 bis 40Tt sich miteinander absprechen. Andererseits ist es mit der Kooperation der Treuhänder 40T1 bis 40Tt auch möglich, den Benutzer (Identifikationsinformation IDU) aus der Information (N, B) und umgekehrt zu verfolgen. Diese Verfolgung ist leicht und beeinträchtigt nicht die Privatsphäre der anderen Benutzer. Die Ausführung der 17 zeigt, als ein Beispiel für eine dezentralisierte Verarbeitung mittels einer Mehrzahl von Treuhändern zum Ausgeben der Lizenz, den Fall, in dem der Benutzer Information mit nur einem Treuhänder allein austauscht, die Mehrzahl der Treuhänder nacheinander Information verarbeitet und die Entsprechungstabelle 40Ti von jedem Treuhänder Information speichert, die sequentiell mit dem Informationenpaar des benachbarten Treuhänders wie dem Paar der Information (Ψi, Ψi–1) in Beziehung steht, es ist jedoch auch möglich, eine Konfiguration einzusetzen, in welcher der Benutzer direkt mit den einzelnen Treuhändern kommuniziert, wobei er sie mit zugehöriger Information versorgt.
  • Vierte Ausführung
  • In der Ausführung der 15 wird die Geheiminformation von jedem Benutzer durch dezentralisierte Verarbeitung einer Mehrzahl von verlässlichen Institutionen (Treuhändern) registriert, durch welche dann, wenn ein Benutzer einen Angriff auf das elektronische Geldsystem, wie z. B. eine Fälschung oder doppelte Ausgabe des elektronischen Geldes, ausführt, der Angreifer aus seiner Transaktionshistorie mit der Kooperation von allen Treuhändern z. B. mit der Genehmigung eines Gerichtes, spezifiziert werden kann. Das System ist jedoch hilflos, wenn der Geheimschlüssel der Bank oder des Treuhänders gestohlen oder erpresst wird.
  • Um eine Straftat zu vermeiden, wenn der Geheimschlüssel von der Bank oder vom Treuhänder gestohlen oder erpresst wird, wird ein zufälliger Wert λ, der verwendet wird, wenn der Benutzer bei der Bank zur Ausgabe elektronischen Geldes anfragt, den Treuhändern 40T1 bis 40Tt als geteiltes Geheimnis anvertraut. Das Geheimnisteilungsschema wird im Einzelnen in A. Schamir, „How to share a secret", Communications of the ACM, Band 24, Nr. 11, November 1979, Seiten 612–613 beschrieben. Für den Fall, dass der Geheimschlüssel der Bank geknackt, gestohlen oder erpresst wird, wird der Zufallswert λ unter Kooperation der Treuhänder 40T1 bis 40Tt wieder hergestellt und es wird eine korrekte Zufallszahlentabelle erstellt und an das Geschäft übermittelt oder sie wird verwendet, um dessen Anfrage zu beantworten, wodurch es möglich ist, den Verdächtigen zum Zeitpunkt seiner Zahlung an das Geschäft zu identifizieren.
  • Dies wird unten stehend beschrieben.
  • 19 stellt im Blockformat eine vierte Ausführung der vorliegenden Erfindung dar. Die Treuhänder 40T1 bis 40Tt , der Benutzer 200, die Bank 100, das Gericht 500 und das Geschäft 300 sind beispielsweise über Kommunikationsleitungen untereinander verbunden, sie können aber auch mittels Chipkarten oder etwas ähnlichem, auf dem Information aufgezeichnet werden kann, untereinander verbunden sein.
  • Das Unterschriftensystem und die öffentliche Schlüsselkryptographie, die in dieser Ausführung verwendet werden, basieren auf dem RSA-Schema, und diese Ausführung kann mittels einer willkürlichen Einwegfunktion g, einem digitalen Unterschriftensystem und einem Kryptosystem mit öffentlichem Schlüssel implementiert werden.
  • Vorab-Prozedur
  • Bei dieser Ausführung sei angenommen, dass der Benutzer die Lizenz B bereits bekommen hat, die vom Treuhänder 400 mittels der Lizenzausgabeprozedur ausgegeben wurde, die zuvor z. B. unter Bezugnahme auf die erste Ausführung, die in 2 gezeigt ist, beschrieben worden ist. Bei dem elektronischen Geldsystem dieser Ausführung vertraut der Benutzer 200 den Zufallswert λ den Treuhändern 40T1 bis 40Tt als geteiltes Geheimnis an, wenn der Benutzer 200 die Bank 100 zur Ausgabe von elektronischem Geld auffordert. Wenn der Geheimschlüssel oder ähnliches von der Bank 100 gestohlen oder erpresst wird, wird der Zufallswert λ mit Kooperation der Treuhänder 40T1 bis 40Tt wieder hergestellt, und es wird eine korrekte Zufallswertetabelle erstellt und an das Geschäft übertragen oder dazu verwendet, um dessen Anfrage zu beantworten, wodurch es möglich ist, den Verdächtigen zur Zeit seiner Zahlung an das Geschäft zu identifizieren.
  • Es wird eine öffentliche Einwegfunktion g vorbestimmt. Die Vorrichtung zu ihrer Berechnung wird nachfolgend als ein g-Rechner bezeichnet. Ein Parameter r zur dezentralisierten Steuerung des Zufallswertes λ. Ein Rechner, der jeweils λ(1), ..., λ(t) mit Bezug auf die Eingaben λ, λ1, ..., λt ausgibt, wird nachfolgend als λ-Rechner bezeichnet. Ein Rechner, der λ mit Bezug auf eine Eingabe {λ(1), ..., λ(t)} ausgibt, wird nachfolgend als ein λ-Entschlüsseler bezeichnet. In diesem Fall ist λ(x) = λ + λ1x + ... +λt–1xt–1(modr)
  • Offensichtlich können der λ-Rechner und der λ-Entschlüsseler durch vier Modulo-Exponentialoperationen ausgeführt werden.
  • Es wird angenommen, dass der Unterschriftenalgorithmus und die Kryptographie mit öffentlichem Schlüssel des Treuhänders 40Ti und der Bank 100 auf dem RSA-Schema basieren. Es seien der Geheimschlüssel und der öffentliche Schlüssel des Treuhänders 40Ti durch (dTi, nTi) und (eTi, nTi) repräsentiert, und der Geheimschlüssel und der öffentliche Schlüssel der Bank 100 durch (dW, nW) und (eW, nW). Es sei die Menge der Treuhänder 40ti durch 40T = (40T1, ..., 40Tt) repräsentiert.
  • Die Unterschrift der Bank 100 wird verwendet, um die Gültigkeit des elektronischen Geldes zu überprüfen.
  • Wenn es notwendig ist, dass das von der Bank 100 ausgegebene elektronische Geld eine Mehrzahl von Geldwerten aufweist, werden Paare von geheimen und öffentlichen Schlüsseln (dW, nW) und (eW, nW) in der Anzahl der Geldwerte entsprechender Zahl vorbereitet, und die Geldwerte und die öffentlichen Schlüssel (eW, nW) werden beide vorher öffentlich gemacht.
  • Prozedur zum Ausgeben elektronischen Geldes
  • Als nächstes wird unter Bezugnahme auf 20 eine Beschreibung der Prozedur gegeben, welcher der Benutzer 200 folgt, um das von der Bank 100 ausgegebene elektronische Geld C zu erhalten. Es sei nun (eW, nW) ein öffentlicher Schlüssel für eine digitale Unterschrift der Bank 100, welche dem vom Benutzer spezifizierten Nennwert (X Yen) des elektronischen Geldes entspricht. Die Prozedur für den Benutzer 200, um von der Bank 100 elektronisches Geld C ausgegeben zu bekommen, ist wie folgt.
  • Schritt 1: Der Benutzer 200 erzeugt den Zufallswert λ mittels eines Zufallsgenerators 220 und speichert ihn im Speicher 20M; darüber hinaus erzeugt der Benutzer 200 Zufallswerte λ1, ..., λt–1, mittels eines Zufallsgenerators 221. Als nächstes verwendet der Benutzer 200 den öffentlichen Parameter r und den aus dem Speicher 20M ausgelesenen Zufallswert λ, um λ(1), ..., λ(t) mittels eines λ-Rechners 201 aus der folgenden Gleichung zu berechnen: λ(x) = λ + λ1x + ... + λt–1xt–1modr
  • Darüber hinaus verwendet der Benutzer 200 öffentliche Schlüssel (eTi, nTi) bis (eTt, nTt) der Treuhänder 40T1 bis 40Tt , um E1(λ(1)) bis Et(λ(t)) mittels öffentlicher Schlüsselkryptographierechner 2021 bis 202t zu berechnen, und sendet sie jeweils an die Treuhänder 40T1 bis 40Tt .
  • Der Benutzer 200 berechnet g(B||λ) aus dem Zufallswert λ und der Lizenz B. Darüber hinaus berechnet der Benutzer 200 ReWmodnW mittels eines Modulo-Exponentialrechners 224 aus dem Zufallswert λ durch den Zufallsgenerator 220 und dem der Nennwertinformation (X Yen) entsprechenden öffentlichen Schlüssel (eW, nW) und berechnet die folgende Gleichung Z = g(B||λ)ReWmodnW mittels eines Modulo-Exponentialrechners 222, um eine Blindvorverarbeitung durchzuführen, und übermittelt Z zusammen mit der Nennwertinformation (X Yen) des elektronischen Geldes C an die Bank 100.
  • Schritt 2: Die Bank 100 verwendet den dem Betrag X des elektronischen Geldes C entsprechenden Geheimschlüssel um Θ = ZdWmodnW mittels eines Modulo-Exponentialrechners 120 zu berechnen, um eine provisorische Unterschrift zu leisten, welche an den Benutzer 200 gesendet wird. Zur selben Zeit zieht die Bank 100 den betreffenden Betrag X vom Konto des Benutzers 200 ab oder empfängt den Betrag X vom Benutzer 200 durch irgendein anderes Mittel.
  • Schritt 3: Der Benutzer 200 verwendet den öffentlichen Schlüssel (eW, nW) des spezifizierten Betrags und einen Zufallswert R, um C = Θ/RmodnW mittels eines inversen Modulo-Rechners 223 zu berechnen, eine Blindvorverarbeitung durchzuführen und um das elektronische Geld C zu erhalten, das im Speicher 20M gespeichert wird. Es muss hier beachtet werden, dass C = g(B||λ)dWmodnW
  • Schritt 4: Wie in 21 dargestellt, verwendet jeder Treuhänder 40Ti den Geheimschlüssel (dTi, nTi) als seinen eigenen, um einen Zufallswert λ(i) mittels eines Entschlüsselers 401; zu berechnen, und speichert ihn im Speicher 40Mi geheim ab.
  • Wenn der Benutzer 200 mit dem elektronischen Geld C bezahlt, sendet er C und B zusammen mit dem Zufallswert λ an das Geschäft 300. Das Geschäft 300 macht unter Verwendung des öffentlichen Schlüssels (eW, nW) der Bank 100 eine Überprüfung, ob C eine autorisierte Unterschrift der Bank 100 ist, welche dem Betrag X entspricht. D. h., es wird überprüft, ob die folgende Gleichung gilt oder nicht, und wenn sie gilt, wird das elektronische Geld C als autorisiert angesehen. CeWmodnW = g(B||λ)modnW
  • Gegenmaßnahmen gegen Straftaten beim elektronischen Geldsystem
  • Das Folgende ist die Prozedur für die Treuhänder 40T1 bis 40Tt , um durch die Verwendung der Speicher 40M1 bis 40Mt auf die Anfrage einer verlässlichen dritten Partei hin, beispielsweise des Gerichts 500 (siehe 22), eine Straftat zu identifizieren.
  • Schritt 1: Auf Anfrage von beispielsweise dem Gericht 500 lesen die Treuhänder 40T1 bis 40Tt die Geheiminformation λ(1) bis λ(t) aus den Speichern 40M1 bis 40Mt aus. Die Geheiminformation λ(1) bis λ(t) und der Parameter r werden zum Entschlüsseln des Zufallswertes I mittels eines λ-Entschlüsselers 430, wie durch die folgende Gleichung gegeben, der in einer λ-Datenbank 440 des Treuhänders 40T gespeichert ist, verwendet. λ(x) = λ + λ1x + ... + λt–1xt–1modr
  • Diese Verarbeitung wird für jeden Zufallswert λ ausgeführt.
  • Schritt 2: Zu der Zeit der Zahlung durch den Benutzer 200 fragt das Geschäft 300 beim Treuhänder 40T an, ob der vom Benutzer 200 empfangene Zufallswert λ in der λ-Datenbank vorhanden ist, und wenn er nicht vorhanden ist, wird der Benutzer 200 als ein Angreifer spezifiziert.
  • Wenn gemäß dieser Ausführung der Geheimschlüssel oder etwas ähnliches von der Bank 100 gestohlen oder erpresst wird, wird der Zufallswert λ mit der Kooperation der Treuhänder 40T1 bis 40Tt wieder hergestellt, und es wird eine korrekte Zufallszahlentabelle erstellt und an das Geschäft oder den Benutzer übertragen, um dessen Anfrage zu beantworten, wodurch es möglich ist, den Verdächtigen zur Zeit seiner Zahlung an das Geschäft zu identifizieren.
  • Wie oben beschrieben, kennt gemäß der ersten und zweiten Ausführung der vorliegenden Erfindung nur der Treuhänder die Entsprechung zwischen der anonymen öffentlichen Information N oder I und der Benutzeridentifikationsinformation IDU; weil aber nur die anonyme öffentliche Information N oder I dem Geschäft zur Verfügung steht, wird die Privatsphäre des Benutzers geschützt, sofern nicht der Treuhänder mit dem Geschäft konspiriert.
  • Um mit Geldwäsche oder anderen Angriffen auf das elektronische Geldsystem fertig zu werden, macht der Treuhänder die Beziehung zwischen dem Benutzernamen und der Information N (oder B) auf Anfrage einer vertrauenswürdigen dritten Partei (z. B. eines Gerichts) öffentlich. Dies beendet Transaktionen, die auf der anonymen öffentlichen Information I basieren. Alternativ dazu kann der Angreifer durch Verfolgen der Transaktionen unter Verwendung der Information N verhaftet werden.
  • Wenn der Treuhänder wie in der dritten Ausführung der Erfindung in eine Mehrzahl von Institutionen aufgeteilt ist, können selbst die Treuhänder die Privatsphäre des Benutzers so lange nicht verletzen, wie sie nicht untereinander konspirieren.
  • Wenn wie in der vierten Ausführung ein Zufallswert λ des Benutzers vor der Anfrage zur Ausgabe von elektronischem Geld bei einer Mehrzahl von Treuhändern registriert wird, ist es möglich, wenn eine Straftat gegen den Benutzer oder die Bank geschieht, den entsprechenden Zufallswert λ mit der Kooperation von allen Treuhändern auf die Anfrage beispielsweise eines Gerichts zu entschlüsseln und ihn dem Geschäft mitzuteilen.
  • Wirkung der Erfindung
  • Die vorliegende Erfindung hat die unten aufgeführten Wirkungen.
  • (a) Gegenmaßnahmen gegen Straftaten
  • Gemäß der vorliegenden Erfindung wird elektronisches Geld durch Zurückgeben der Kommunikationshistorie an die Bank realisiert, so dass dann, wenn der Benutzer das elektronische Geld C zwei oder mehrere Male ausgibt, die Bank dies durch Abrufen der Kommunikationshistoriendateien auf der Basis der Information C erkennen kann. Weil die Kommunikationshistorieninformation H sowohl die Information N als auch die Information C enthält, kann die Bank den Namen des Benutzers (Identifikationsinformation IDU) entsprechend der Information N vom Treuhänder durch legale Erlaubnis einer dritten Partei (z. B. eine Gerichtsanordnung) erfahren, und sie kann daher den Benutzer, der das hinterhältige Spiel begangen hat, identifizieren.
  • Darüber hinaus können die Bank und der Treuhänder miteinander kooperieren, um die Beziehung zwischen der Identifikationsinformation ID und der Information (I, N) auf eine legale Abfrage oder Erlaubnis einer dritten Partei (z. B. eines Gerichts) zu ermitteln. Dadurch ist es selbst dann, wenn in der Verarbeitung von elektronischem Geld nichts Falsches gefunden wird, möglich, das elektronische Geld und/oder den der Geldwäscherei oder nichtautorisierten Finanzierung verdächtigten Benutzer zu verfolgen.
  • (b) Benutzerprivatsphäre
  • Die Chipkarte kann die Privatsphäre des Benutzers nicht sicherstellen, weil die Benutzeridentifikationsinformation ID dem Geschäft direkt zugänglich ist. Das Chaum/Fiat/Naor-Schema verwendet die Blindunterschrift, und der Benutzer kann daher seine Privatsphäre selber schützen, es sei aber hervorgehoben, dass dieses manchmal zu einem Nährboden für Straftaten werden kann.
  • Bei der vorliegenden Erfindung kennt die Bank die Entsprechung zwischen der Identifikationsinformation IDU und der anonymen öffentlichen Information (N oder I) des Benutzers nicht, und kann daher dessen Privatsphäre nicht verletzen, es sei denn, dass die Bank mit dem Treuhänder konspiriert.
  • Wenn darüber hinaus der Treuhänder in eine Mehrzahl von Institutionen aufgeteilt ist, können selbst diese nicht in die Privatsphäre des Benutzers eindringen, solange sie nicht miteinander konspirieren.
  • (c) Verkehr und Betrag der gespeicherten Information
  • Weil im Chaum/Fiat/Naor-Schema, welches die Privatsphäre des Benutzers schützt, der Benutzer die Identifikationsinformation ID in das elektronische Geld einfügt, wird ein Schneid- und Auswahlverfahren (cut-and-choose method) benötigt, um zu überprüfen, ob der Benutzer wie vor handelt, und der Umfang der Kommunikation zum Ausgeben der Lizenz ist groß. Ein weiteres Problem besteht in dem großen Umfang der Information der Kommunikationshistorie H, die von der Bank gespeichert werden muss, um doppelte Verwendung von elektronischem Geld zu erfassen.
  • Weil gemäß der vorliegenden Erfindung der Treuhänder und die Bank die Lizenzausgabeprozedur und die Ausgabeprozedur für elektronisches Geld unabhängig voneinander ausführen, kann der Umfang der Information, die zum Ausgeben des elektronischen Geldes verarbeitet werden muss, reduziert werden. Weil zwei Prozeduren von zwei derart voneinander unabhängigen Institutionen ausgeführt werden, ist es möglich, die Privatsphäre des Benutzers zu schützen und den Umfang der zu verarbeitenden Information selbst dann zu reduzieren, wenn das Schneid- und Auswahlverfahren nicht eingesetzt wird (es sei angenommen, dass die Lizenz über eine festgesetzte Zeitdauer verfügbar ist). Indem man die dem Treuhänder, der die Lizenz ausgibt, verfügbare Privatsphäre des Benutzers begrenzt, wird der Umfang der zum Ausgeben der Lizenz zu verarbeitenden Information reduziert. Bei dem Chaum/Fiat/Naor-Verfahren wird unter Sicherheitsgesichtspunkten vorgeschlagen, dass der Wert von K bei der Schneid- und Wählprozedur normalerweise ungefähr 30 betragen soll, jedoch verwendet die vorliegende Erfindung nicht die Schneid- und Wählprozedur, d. h., der Wert K wird auf I gesetzt, so dass der Umfang der Kommunikation zum Ausgeben der Lizenz auf 1/20 dessen, was beim Chaum/Fiat/Naor-Verfahren benötigt wird, reduziert werden kann.
  • (d) Doppelte Verwendung, Teilung und Übertragung
  • Gemäß der vorliegenden Erfindung kann eine Übertragung oder Gutschein-Karten-ähnliche Verwendung des elektronischen Geldes, welche beim Chaum/Fiat/Naor-Verfahren unmöglich ist, implementiert werden, indem man unversehrt den Doppelverwendungserfassungsalgorithmus verwendet. Indem man z. B. eine Unterschrift leistet, welche die Zahlung (Übertragung) eines Geldbetrages x (wobei x ≤ X) versichert, kann das elektronische Geld C, das den Geldbetrag X wert ist, geteilt (übertragen) und entsprechend verwendet werden.

Claims (24)

  1. Verfahren zum Implementieren von elektronischem Geld für ein elektronisches Geldsystem, das einen Treuhänder (400) und eine Bank (100) umfasst, wobei das Verfahren die folgenden Schritte umfasst: (1) ein Benutzer (200) überträgt seine Benutzeridentifikationsinformation (IDU) und anonyme Information an den Treuhänder; (2) der Treuhänder speichert die Entsprechung zwischen der Benutzeridentifikationsinformation und der anonymen Information in einer Entsprechungstabelle (41T) geheim ab und erzeugt und überträgt eine der anonymen Information entsprechende digitale Unterschrift B an den Benutzer; (3) der Benutzer speichert die digitale Unterschrift B des Treuhänders als eine Lizenz, legt der Bank die Lizenz und einen Nennwert X vor und bittet die Bank, elektronisches Geld entsprechend dem Nennwert X auszugeben; (4) die Bank überträgt an den Benutzer eine Blindunterschrift zu dieser Lizenz; und (5) der Benutzer extrahiert aus dem Ergebnis der Blindunterschrift die Unterschrift der Bank zu dieser Lizenz und verwendet sie als das elektronische Geld C, das mit der Lizenz in Verbindung steht und dem Nennwert X entspricht; dadurch gekennzeichnet, dass die anonyme Information der anonyme öffentliche Schlüssel (N) des Benutzers ist.
  2. Verfahren nach Anspruch 1, das die weiteren Schritte umfasst: (5) wobei der Benutzer (200) einem Geschäft (300) diesen anonymen öffentlichen Schlüssel, diese Lizenz und dieses elektronische Geld zeigt, und diesen anonymen öffentlichen Schlüssel verwendet, um eine Zahlungsunterschrift S zu erzeugen, was die Zahlung des ausgegebenen Geldbetrages sicherstellt, und diese Unterschrift diesem Geschäft bereitstellt; und (6) wobei das Geschäft eine Zahlungshistorieninformation H an die Bank (100) liefert, um damit eine Rechnung zu begleichen und einen diesem ausgegebenen Betrag entsprechenden Geldbetrag zu erhalten.
  3. Verfahren nach Anspruch 2, das darüber hinaus einen Schritt umfasst, bei dem die Bank (100) eine Überprüfung macht, um zu sehen, ob der mit dem elektronischen Geld bezahlte Gesamtbetrag diesen Nennwert X übersteigt, und wenn dem so ist, wenigstens diesen anonymen öffentlichen Schlüssel einer Historie aller Zahlungen mit diesem elektronischen Geld extrahiert und ihn an den Treuhänder (400) überträgt.
  4. Verfahren nach Anspruch 1 oder 2, das darüber hinaus einen Schritt umfasst, bei dem diese Bank (100) und dieser Treuhänder (400) dann, wenn sie eine offizielle Anweisung oder Erlaubnis einer dritten Partei empfangen, jeweils eine Identifikationsinformation oder einen anonymen öffentlichen Schlüssel eines von der dieser dritten Partei bezeichneten Benutzers (200) aus der unter die Aufsicht dieser Bank gestellten Kommunikationshistorie und dieser unter der Aufsicht dieses Treuhänders gehaltenen Entsprechungstabelle (41T) wiedergewinnen und diese dritte Partei über die wiedergewonnene Identifikationsinformation und den anonymen öffentlichen Schlüssel informieren.
  5. Verfahren nach Anspruch 1, das die weiteren Schritte umfasst: (5) wobei ein erster Benutzer (200) als dieser Benutzer diese Lizenz und das elektronische Geld C dieses ersten Benutzers einem zweiten Benutzer (500) zeigt; und (6) wobei der erste Benutzer seinen anonymen öffentlichen Schlüssel N1 verwendet, um eine Übertragungsunterschrift zu erzeugen, welche die Übertragung eines Teilbetrages x sicherstellt, der kleiner ist als dieser Nennwert X, und diese Übertragungsunterschrift dem zweiten Benutzer bereitstellt.
  6. Verfahren nach Anspruch 5, das darüber hinaus einen Schritt umfasst, bei dem dieser zweite Benutzer (500) einem Geschäft (300) eine Historie des elektronischen Geldes zur Zeit der Übertragung und diese Lizenz dieses zweiten Benutzers zeigt und einen anonymen öffentlichen Schlüssel N2 dieses zweiten Benutzers verwendet, um eine Unterschrift zu erzeugen, welche die Zahlung eines Betrages y sicherstellt, die kleiner ist als der Teilbetrag, und sie diesem Geschäft bereitstellt, um die Zahlung an selbiges zu machen.
  7. Verfahren nach Anspruch 1, bei dem diese digitale Unterschrift im Schritt (2) durch ein auf dem RSA-Schema basierendes digitales Unterschriftenverfahren erzeugt wird, und die Blindunterschrift im Schritt (4) durch ein auf dem RSA-Schema basierendes Blindunterschriftenverfahren erzeugt wird.
  8. Verfahren nach Anspruch 2, bei dem die Zahlungsunterschrift im Schritt (5) durch ein auf dem RSA-Schema basierendes digitales Unterschriftenverfahren erzeugt wird.
  9. Verfahren nach Anspruch 5, bei dem die Übertragungsunterschrift im Schritt (6) durch ein auf dem RSA-Schema basierendes digitales Unterschriftenverfahren erzeugt wird.
  10. Verfahren nach Anspruch 1, bei dem die digitale Unterschrift im Schritt (2) durch ein auf einem RSA-Schema basierendes digitales Unterschriftenverfahren erzeugt wird, und die Blindunterschrift im Schritt (4) durch ein Blindunterschriftenverfahren erzeugt wird, das auf einem interaktiven Beweis mit Null-Wissen basiert.
  11. Verfahren nach Anspruch 2, bei dem die Zahlungsunterschrift im Schritt (5) durch ein auf einem ESIGN-Schema basierendes digitales Unterschriftenverfahren erzeugt wird.
  12. Verfahren nach Anspruch 7, wobei: der Benutzer (200) im Schritt (1): zwei große Primzahlen P und Q erzeugt, diese Primzahlen verwendet, um eine zusammengesetzte Zahl N = P × Q als diesen anonymen öffentlichen Schlüssel zu berechnen; die folgende modulare inverse Berechnung d = e–1modLCM(P – 1, Q – 1)aus diesen Primzahlen P und Q und einem Schlüssel e, der allen Benutzern bekannt ist, durchführt, wobei LCM(P – 1, Q – 1) das kleinste gemeinsame Vielfache repräsentiert; d und N in einem Speicher speichert; und N an den Treuhänder (400) überträgt; der Treuhänder im Schritt (2): die Entsprechung zwischen dem Benutzer und dem N in der Entsprechungstabelle (41T) geheim hält; eine Information I über die Gültigkeitsdauer oder Ähnliches erzeugt; mittels Einwegfunktion, g-Berechnung und modularer Exponentialberechnung die durch die folgende Gleichung ausgedrückte digitale Unterschrift B = g(N||I)dWmodnB durch die Verwendung eines Geheimschlüssels (dB, RB) als die Unterschrift des Treuhänders erzeugt; und die Unterschrift B und diese Information I an den Benutzer versendet; der Benutzer im Schritt (3) Information (B, I, N) vom Treuhänder als die Lizenz in einem Speicher speichert; einen Zufallswert b erzeugt und in dem Speicher speichert; eine Einwegfunktion g(B||b) aus dem Zufallswert b und der aus dem Speicher ausgelesenen Lizenz (B, I, N) berechnet; die folgende Gleichung
    Figure 00430001
    durch die Verwendung von dem Nennwert entsprechender öffentlicher Information (eC, nC) dieser Bank (100) berechnet; und die Information Z zusammen mit der Betragsinformation des elektronischen Geldes an die Bank überträgt; und die Bank im Schritt (4): die folgende Gleichung
    Figure 00430002
    durch die Verwendung dieses Z, das sie vom Benutzer empfangen hat, und eines dem Nennwert des elektronischen Geldes entsprechenden Geheimschlüssels (dC, nC) berechnet; und die Information Θ an den Benutzer überträgt; und der Benutzer die folgende Gleichung C = Θ/rmodnC durch die Verwendung dieser Information Θ, die er von der Bank empfangen hat, und des öffentlichen Schlüssels (eC, nC) berechnet, wodurch er das elektronische Geld C mit dem spezifizierten Nennwert erhält.
  13. Verfahren nach Anspruch 8, wobei der Schritt (5) die folgenden Schritte umfasst: (5-1) wobei der Benutzer (200): eine Information {I, N, B, b, C} an das Geschäft (300) sendet; (5-2) wobei das Geschäft: die Gültigkeit der digitalen Unterschrift B für die Information (I, N) durch Überprüfen verifiziert, ob dieses B unter Verwendung eines öffentlichen Schlüssels (eB, nB) als Unterschrift des Treuhänders (400)
    Figure 00440001
    erfüllt; die Gültigkeit des elektronischen Geldes C für eine Information (B, b) durch Überprüfen verifiziert, ob dieses C unter Verwendung des öffentlichen Schlüssels (eC, nC) der Bank (100) die folgende Gleichung
    Figure 00440002
    erfüllt; wenn irgendeine der Verifikationen fehlschlägt, die nachfolgende Verarbeitung anhält; wenn beide Verifikationen erfolgreich sind, einen Zufallswert E' erzeugt und ihn zusammen mit der Identifikationsinformation IDV und einem Zeitstempel T an diesen Benutzer sendet; und dafür E = h(IDV||T||E') durch die Verwendung einer Einwegfunktion h berechnet; (5-3) der Benutzer: die folgende Gleichung S = g(x||h(IDV||T||E'))dmodNals eine Zahlungsunterschrift für den ausgegebenen Betrag x des elektronischen Geldes C und die vom Geschäft empfangene Information durch die Verwendung eines Geheimschlüssels (d, N) des Benutzers berechnet; und diese Zahlungsunterschrift S und diese Information x an das Geschäft sendet; und der Schritt (6) die folgenden Schritte umfasst: (6-1) das Geschäft macht eine Überprüfung, um zu sehen, ob dieser ausgegebene Betrag x kleiner ist als der Nennwert X des elektronischen Geldes C; hält, wenn die Überprüfung nicht bestanden wird, die nachfolgende Verarbeitung an; und verifiziert, wenn die Überprüfung bestanden wird, die Gültigkeit dieser Zahlungsunterschrift S durch Überprüfung, ob dieses S die folgende Gleichung erfüllt Se ≡ g(x||E)(modN);und (6-2) wenn diese Verifizierung erfolgreich ist, sieht das Geschäft die Zahlung des diesem Betrag x entsprechenden Betrages als gültig an und akzeptiert sie vom Benutzer.
  14. Verfahren nach Anspruch 9, bei dem: der Schritt (5) die folgenden Schritte umfasst: (5-1) der erste Benutzer (200) sendet die Lizenz (B1, I1, N1) und das elektronische Geld (b, C) an den zweiten Benutzer (500); (5-2) der zweite Benutzer: verifiziert die Gültigkeit einer Unterschrift B1 für dieses (I1, N1) durch Überprüfen, ob dieses B1 die folgende Gleichung erfüllt
    Figure 00440003
    verifiziert die Gültigkeit des elektronischen Geldes C für dieses (B1, b) durch Überprüfen, ob dieses C die folgende Gleichung erfüllt
    Figure 00450001
    hält, wenn irgendeine dieser Überprüfungen nicht bestanden wird, die nachfolgende Verarbeitung an; und erzeugt, wenn beide Überprüfungen bestanden werden, einen Zufallswert E2' und sendet ihn an den ersten Benutzer zusammen mit einer Unterschrift B2 für den zweiten Benutzer und berechnet E = h(B2||T||E2'); und der Schritt (6) die folgenden Schritte umfasst: (6-1) der erste Benutzer: berechnet eine Unterschrift für den aus dem elektronischen Geld C abzuteilenden Betrag x durch die folgende Gleichung
    Figure 00450002
    und sendet die Unterschrift St und diesen Betrag x an den zweiten Benutzer; und (6-2) der zweite Benutzer: macht eine Überprüfung, um zu sehen, ob dieser Betrag x kleiner ist als der maximale Betrag X des elektronischen Geldes C; hält, wenn die Überprüfung nicht bestanden wird, die nachfolgende Verarbeitung an; verifiziert, wenn die Überprüfung bestanden wird, die Gültigkeit der Unterschrift St durch Überprüfen, ob dieses St die folgende Gleichung erfüllt
    Figure 00450003
    wenn diese Überprüfung bestanden wird, sieht der zweite Benutzer die Übertragung des Betrages im Wert dieses Betrages x vom ersten Benutzer als gültig an und akzeptiert sie.
  15. Verfahren nach Anspruch 14, das darüber hinaus die folgenden Schritte umfasst: (7) der zweite Benutzer (500) sendet an das Geschäft (300) die zweite Lizenz (B2, I2, N2) und eine Historie H1 (I1, B1, N1, B1, b, C, x, T, E2', S1) der Kommunikationen, die mit dem ersten Benutzer ausgeführt wurden, als das elektronische Geld übertragen wurde; (8) das Geschäft: verifiziert die Gültigkeit der Unterschrift B2 des zweiten Benutzers für (I2, N2) durch Überprüfen, ob dieses B2 die folgende Gleichung erfüllt
    Figure 00450004
    und verifiziert die Gültigkeit der Kommunikationshistorie H1; hält die nachfolgende Verarbeitung an, wenn irgendeine dieser Überprüfungen nicht bestanden wird; erzeugt, wenn beide Überprüfungen bestanden werden, einen Zufallswert EV' und sendet ihn an den zweiten Benutzer zusammen mit einer Identifikationsinformation IDV' und einem Zeitstempel T' und berechnet EV = H(IDV||T'||EV');(9) der zweite Benutzer: erzeugt eine Unterschrift S2 für einen Betrag y, der von diesem übertragenen Betrag x zum Ausgeben abgeteilt wird, durch die folgende Gleichung
    Figure 00450005
    und sendet diese Unterschrift S2 und diesen Betrag y an das Geschäft; (10) das Geschäft: macht eine Überprüfung um zu sehen, ob der Betrag y kleiner ist als der von dem elektro nischen Geld C zum Übertragen abzuteilende Betrag; hält die nachfolgende Verarbeitung an, wenn diese Verifikation nicht bestanden wird; verifiziert, wenn diese Verifikation erfolgreich ist, die Gültigkeit dieser Unterschrift S2 durch Überprüfen, ob dieses S2 die folgende Gleichung erfüllt
    Figure 00460001
    sieht, wenn diese Verifizierung erfolgreich ist, die Zahlung als vom Wert y an und akzeptiert sie vom zweiten Benutzer.
  16. Verfahren nach Anspruch 10, wobei: der Benutzer (200) im Schritt (1): zwei große Primzahlen P und Q erzeugt, diese Primzahlen verwendet, um eine zusammengesetzte Zahl N = P2 × Q als den anonymen öffentlichen Schlüssel zu berechnen; d und N in einem Speicher speichert; und N an den Treuhänder (400) überträgt; der Treuhänder im Schritt (2): die Entsprechung zwischen Benutzer und dem N in der Entsprechungstabelle (41T) geheim hält; eine Information I über die Gültigkeitsdauer oder Ähnliches erzeugt; die folgende Gleichung
    Figure 00460002
    durch die Verwendung eines Geheimschlüssels (dB, nB) als Unterschrift des Treuhänders berechnet; und dieses B und die Information I an den Benutzer überträgt; der Benutzer im Schritt (3): (3-1) Information (B, I, N) vom Treuhänder als eine Lizenz in einem Speicher speichert; (3-2) die Bank (100) auf eine Anfrage des Benutzers nach Abhebung des elektronischen Geldes antwortet, um einen Zufallswert r zu erzeugen, und die folgende Gleichung berechnet
    Figure 00460003
    und sie an den Benutzer überträgt; (3-3) der Benutzer Zufallswerte r' und b erzeugt, die folgende Gleichung berechnet
    Figure 00460004
    und sie in einem Speicher speichert, und die folgende Gleichung berechnet c = g(B||a)modnC und sie in einem Speicher speichert, die folgende Gleichung berechnet c' = c + bmodLC und sie an die Bank überträgt; die Bank im Schritt (4): (4-1) die folgende Gleichung y' = rxc cmodnC durch die Verwendung eines dem Nennwert des elektronischen Geldes entsprechenden öffentlichen Schlüssels (hC, LC, nC) und eines Geheimschlüssels xC berechnet, sie an den Benutzer überträgt und zur selben Zeit die betroffene Menge vom Konto des Benutzers abbucht oder diesen Betrag vom Benutzer durch irgendein anderes Mittel empfängt; und (4-2) der Benutzer d berechnet, welches die folgende Gleichung erfüllt c' = c + b + dLund die folgende Gleichung berechnet y = y'r'h–dmodnC und sie zusammen mit a und c in der Form von elektronischem Geld C = (a, c, y) in einem Speicher speichert.
  17. Verfahren nach Anspruch 11, wobei: der Schritt (5) die folgenden Schritte umfasst: (5-1) der Benutzer (200) sendet I, N, B, C an das Geschäft (300); (5-2) das Geschäft verifiziert die Gültigkeit einer Unterschrift B für (I, N) durch Überprüfen, ob dieses B die folgende Gleichung
    Figure 00470001
    erfüllt, durch die Verwendung eines öffentlichen Schlüssels (eB, nB) als Unterschrift des Treuhänders (400), und verifiziert die Gültigkeit des elektronischen Geldes für diese Unterschrift B durch Überprüfen, ob dieses C die folgende Gleichung erfüllt
    Figure 00470002
    c = g(B||a)hält, wenn diese Verifizierung fehl schlägt, die nachfolgende Verarbeitung an; wenn diese Verifizierung erfolgreich ist, erzeugt das Geschäft einen Zufallswert E' und sendet ihn zusammen mit der Identifikationsinformation IDU und einem Zeitstempel T an den Benutzer und berechnet E = h(IDV||T||E') durch die Verwendung einer Einwegfunktion h; und (5-3) der Benutzer: bestimmt, dass er einen Betrag x des elektronischen Geldes C ausgibt, berechnet die folgende Gleichung m = x||h(IDV||T||E')und erzeugt eine ESIGN-Unterschrift S durch die folgende Gleichung S = ESIG (m, p, q)durch die Verwendung eines Geheimschlüssels (p, q) des Benutzers und sendet den Betrag x und diese Unterschrift S an das Geschäft; und der Schritt (6) die Schritte umfasst: (6-1) das Geschäft macht eine Überprüfung, um zu sehen, ob dieser Betrag x den maximalen Betrag X des elektronischen Geldes C übertrifft; hält, wenn diese Überprüfung fehlschlägt, die nachfolgende Verarbeitung an; verifiziert, wenn die Überprüfung bestanden wird, die Gültigkeit der ESIGN-Unterschrift S durch die folgende Gleichung EVER(m, S, N) = OK/NGdurch die Verwendung der Informationsteile m, S und N; und wenn diese Verifizierung erfolgreich ist, sieht das Geschäft die Zahlung eines Betrages im Wert dieses x als gültig an und akzeptiert sie vom Benutzer.
  18. Verfahren nach Anspruch 17, das die weiteren Schritte umfasst: (7) das Geschäft (300) legt der Bank (100) eine Historie H der mit dem Benutzer (200) durchgeführten Kommunikation zum Ausgeben des elektronischen Geldes vor; (8) die Bank verifiziert die Gültigkeit der Kommunikationshistorie H und speichert die Historie H, wenn diese Verifizierung erfolgreich ist, und zahlt einen betreffenden Betrag auf ein Konto dieses Geschäftes oder zahlt diese Menge mittels irgendeines anderen Mittels an das Geschäft; (9) stellt die Bank diese Historie H unter ihre Aufsicht, um zu verhindern, dass das elektronische Geld C über den maximalen Betrag X hinaus ausgegeben wird, und legt, wenn dieses Geld C über den der maximalen Betrag X hinaus ausgegeben wird, eine Historie von allen Zahlungen mit diesem elektronischen Geld C als Beweis für einen Angriff vor; und (10) der Treuhänder (400) findet den Namen des Benutzers aus der Entsprechungstabelle (41T) auf der Basis von diesem N heraus, das in der Kommunikationshistorie H enthalten ist, und identifiziert den Angreifer.
  19. Verfahren nach Anspruch 1, wobei der Treuhänder (400) aus einer Mehrzahl von Institutionen gebildet ist und der Schritt (2) ein Schritt ist, bei dem die Entsprechung zwischen der Benutzeridentifikationsinformation IDU und dem anonymen öffentlichen Schlüssel N als Information zwischen dieser Mehrzahl von Institutionen verteilt wird.
  20. Verfahren nach Anspruch 19, wobei im Schritt (2) die mehrere Institutionen die Entsprechung zwischen der Benutzeridentifikationsinformation IDU und dem anonymen öffentlichen Schlüssel N in einer sequentiell korrespondierenden Weise durch unterschiedliche Paare von sequentiell assoziierten Teilen von Information speichern, so dass nur dann, wenn diese mehreren Institutionen kooperieren, die Entsprechung zwischen dem anonymen öffentlichen Schlüssel N und der Identifikationsinformation IDU aus den assoziierten Teilen von Information ermittelt werden kann.
  21. Verfahren nach Anspruch 20, bei dem die Mehrzahl von Institutionen t Institutionen 40T1 bis 40Tt sind und der Schritt (1) die folgenden Schritte umfasst: (1-1) wobei der Benutzer (200) Schlüssel k1 bis kt in einer Eins-zu-eins-Entsprechung zu den t Institutionen 40T1 bis 40Tt erzeugt, wenn er den anonymen öffentlichen Schlüssel N bei den t Institutionen registriert; (1-2) wobei der Benutzer eine Kryptographiefunktion Ei mit öffentlichem Schlüssel jeder Institution 40Ti verwendet, um rekursiv ϕi = Ei(ki||ϕi–1) für 1 ≤ i ≤ t zu berechnen, um schließlich ϕt zo erhalten, wobei ϕ0 die Identifikationsinformation IDU des Benutzers ist; und (1-3) wobei der Benutzer rekursiv Φi = Eio ... oEt(N||ϕt) berechnet, wobei EioEj(x) Ei(Ej(x)) repräsentiert, wobei das Φ1 an die erste Institution 40T1 übertragen wird; und der Schritt (2) die folgenden Schritte umfasst: (2-1) die erste Institution verwendet eine öffentliche Schlüsselentschlüsselungsfunktion D1, um Φ2 = D1(Φ1) zu berechnen, und überträgt es an die zweite Institution 40T2 , und für i = 1, ... t – 1 verwendet jede Institution 40Ti die öffentliche Schlüsselentschlüsselungsfunktion Di, um Φi+1 = Di(Φi) zu berechnen und sie an die Institution 40Ti+1 zu übertragen, so dass die Institution 40Tt schließlich Φt erhält; (2-2) die Institution 40Tt verwendet die öffentliche Schlüsselentschlüsselungsfunktion Dt, um (N||ϕt) = Dt(Φt) aus Φt und (kt||ϕt–1) = Dt(Φt) aus ϕt zu berechnen, und erhält schließlich (N, ϕt–1, kt); (2-3) die Institution 40Tt erzeugt eine digitale Unterschrift für den anonymen öffentlichen Schlüssel N, verschlüsselt die digitale Unterschrift B zu Ψt = εkt(B), wobei sie kt als einen Geheimschlüssel verwendet, speichert N, B und ϕt in einem Speicher und überträgt (ϕt–1, Ψt) an die Institution 40Tt–1 ; (2-4) wobei die Institution 40Ti (ki||ϕi–1) = Di(ϕi) aus ϕi berechnet, Ψi+1, zu Ψi = eki(Ψi+1) verschlüsselt, indem sie ki als einen Geheimschlüssel verwendet, dann ein Paar miteinander verbundener Teile von Information (Ψi, Ψi+1) speichert und (ϕi–1, Ψi) an die Institution 40Ti–1 überträgt, und diese Folge von Operationen für i = t – 1, t – 2, ... 2 wiederholt wird, so dass die Institution 40T2 schließlich (ϕ1, Ψ2) erhält; (2-5) wobei die Institution 40T1 (k1||IDU) = D1(ϕ1) aus ϕ1 berechnet, den Benutzer auf der Grundlage dieser Identifikationsinformation IDU identifiziert, Ψ, = εk1(Ψ2) aus k1 und Ψ2 berechnet, IDU, Ψ2 und Ψ1 in einem Speicher 40M1 speichert und Ψ1 an den Benutzer überträgt; und (2-6) wobei der Benutzer die digitale Unterschrift B vom Treuhänder (400) gemäß der folgenden Gleichung B = δkto ... oδk1(Ψ1) = g(N)dTmodnTdurch die Verwendung von Entschlüsselern δ für (k1, ..., kt) und ε erhält.
  22. Verfahren nach Anspruch 1, wobei der Treuhänder (400) aus t unabhängigen Institutionen 40T1 bis 40Tt gebildet ist, wobei t eine ganze Zahl ist, die gleich oder größer ist als 2, und die darüber hinaus den Schritt umfasst, bei dem, wenn von der Bank (100) ausgegebenes elektronisches Geld empfangen wird, der Benutzer (200) einen diesem elektronischen Geld C entsprechenden Zufallswert λ und t – 1 Zufallswerte λ1, ..., λt–1, erzeugt und E1(λ(1)), ..., Et(λ(t)) für diese t Institutionen unter Verwendung von Verschlüsselern E1, ..., Et mit öffentlichem Schlüssel berechnet, wobei λ(x) = λ + λ1x + ... + λt–1xt–1modr, wobei diese E1(λ(1)), ..., Et(λ(t)) an jede der t Institutionen übertragen werden.
  23. Verfahren nach Anspruch 22, das den weiteren Schritt umfasst, bei dem, wenn eine offizielle Anfrage oder Erlaubnis von einer dritten Partei empfangen wird, die t Institutionen miteinander kooperieren, um die Zufallswerte λ zu entschlüsseln und sie in eine Datenbank zu schreiben.
  24. Verfahren nach Anspruch 23, wobei die Zufallswertentschlüsselungsverarbeitung eine Verarbeitung umfasst, bei der die t Institutionen jeweils Teile von geheimer Information λ(1), ..., λ(t) aus den E1(λ(1)), ..., Et(λ(t)) durch die entsprechenden öffentlichen Schlüssel extrahieren und λ1, ..., λt–1 aus den Teilen der geheimen Information und einem Parameter r berechnen, wobei λ1, ..., λτ–1 die folgende Gleichung erfüllen λ(x) = λ + λ1x + ... + λt–1xt–1modr.
DE69633217T 1995-11-06 1996-11-05 Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels Expired - Fee Related DE69633217T2 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP28745795A JP3171227B2 (ja) 1995-11-06 1995-11-06 信託機関付き電子紙幣実施方法
JP28745795 1995-11-06
JP5753796 1996-03-14
JP5753696 1996-03-14
JP5753696A JP3104904B2 (ja) 1996-03-14 1996-03-14 匿名登録方法
JP5753796A JP3171228B2 (ja) 1996-03-14 1996-03-14 複数信託機関を利用した電子紙幣実施方法

Publications (2)

Publication Number Publication Date
DE69633217D1 DE69633217D1 (de) 2004-09-30
DE69633217T2 true DE69633217T2 (de) 2005-07-14

Family

ID=27296295

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69633217T Expired - Fee Related DE69633217T2 (de) 1995-11-06 1996-11-05 Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels

Country Status (3)

Country Link
US (1) US5901229A (de)
EP (1) EP0772165B1 (de)
DE (1) DE69633217T2 (de)

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US6945457B1 (en) 1996-05-10 2005-09-20 Transaction Holdings Ltd. L.L.C. Automated transaction machine
DE69738743D1 (de) * 1996-05-16 2008-07-17 Nippon Telegraph & Telephone Verfahren zum Einführen elektronischen Geldes mit einer Überwachungseinrichtung, Gebrauchervorrichtung und Überwachungseinrichtung zum Durchführen desselben
US6742125B1 (en) * 1996-11-13 2004-05-25 Lucent Technologies Inc. Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
JP3877188B2 (ja) * 1997-04-10 2007-02-07 株式会社ウェブマネー 電子通貨システム
US6311171B1 (en) 1997-07-11 2001-10-30 Ericsson Inc. Symmetrically-secured electronic communication system
WO1999026207A1 (en) * 1997-11-19 1999-05-27 Rsa Security Inc. Digital coin tracing using trustee tokens
EP0926637B1 (de) * 1997-12-26 2005-04-27 Nippon Telegraph and Telephone Corporation Verfahren zum Einführen von elektronischem Geld für einen Emittent mit elektronischen Saldo-Zählern, entsprechende Vorrichtung und Speicherelement mit gespeichertem Programm zur Durchführung des Verfahrens
KR100358426B1 (ko) * 1998-08-18 2003-01-29 한국전자통신연구원 전자현금거래방법
US20010011247A1 (en) * 1998-10-02 2001-08-02 O'flaherty Kenneth W. Privacy-enabled loyalty card system and method
US7222108B2 (en) * 1998-12-23 2007-05-22 Nippon Telegraph And Telephone Corporation Electronic cash implementing method and equipment using user signature and recording medium recorded thereon a program for the method
US6578144B1 (en) * 1999-03-23 2003-06-10 International Business Machines Corporation Secure hash-and-sign signatures
US6636969B1 (en) * 1999-04-26 2003-10-21 Lucent Technologies Inc. Digital signatures having revokable anonymity and improved traceability
WO2000070487A1 (en) 1999-05-14 2000-11-23 Frenkel Marvin A Anonymous on-line cash management system
WO2001033458A1 (en) * 1999-10-29 2001-05-10 Singleshop.Com System and method of aggregate electronic transactions with multiple sources
US7222097B2 (en) * 2000-01-18 2007-05-22 Bellosguardo Philippe A Anonymous credit card
US20030158782A1 (en) * 2000-05-17 2003-08-21 Scott Thomson Electronic processing system
US7162035B1 (en) 2000-05-24 2007-01-09 Tracer Detection Technology Corp. Authentication method and system
US7225169B1 (en) * 2000-05-26 2007-05-29 International Business Machines Corporation Method and system for commerce with full anonymity
JP2001344537A (ja) * 2000-05-31 2001-12-14 Ntt Docomo Inc 電子バリューシステム、通信端末及びサーバ
US6976162B1 (en) 2000-06-28 2005-12-13 Intel Corporation Platform and method for establishing provable identities while maintaining privacy
US20020002545A1 (en) * 2000-06-29 2002-01-03 Resneck James D. Electronic money transaction device and method
US7447661B2 (en) * 2000-07-24 2008-11-04 Raja Ahsan I Electronic bearer bond online transaction system
US7360080B2 (en) * 2000-11-03 2008-04-15 International Business Machines Corporation Non-transferable anonymous credential system with optional anonymity revocation
US7224806B2 (en) * 2000-11-13 2007-05-29 Thomson Licensing Threshold cryptography scheme for conditional access systems
AU2002243223A1 (en) * 2000-11-15 2002-06-24 Robert P Arbuckle System and method for guiding a computer user to promotional material
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
CA2347528A1 (en) * 2001-05-15 2002-11-15 Ibm Canada Limited-Ibm Canada Limitee System and method for on-line payment
US7110525B1 (en) 2001-06-25 2006-09-19 Toby Heller Agent training sensitive call routing system
US6990471B1 (en) * 2001-08-02 2006-01-24 Oracle International Corp. Method and apparatus for secure electronic commerce
US7308576B2 (en) * 2001-12-31 2007-12-11 Intel Corporation Authenticated code module
US7372952B1 (en) 2002-03-07 2008-05-13 Wai Wu Telephony control system with intelligent call routing
US6805289B2 (en) 2002-05-23 2004-10-19 Eduardo Noriega Prepaid card payment system and method for electronic commerce
SG145524A1 (en) * 2002-08-07 2008-09-29 Mobilastic Technologies Pte Lt Secure transfer of digital tokens
US8171567B1 (en) 2002-09-04 2012-05-01 Tracer Detection Technology Corp. Authentication method and system
GB0227958D0 (en) * 2002-11-29 2003-01-08 Q P Q Ltd Electronic processing system
US9818136B1 (en) 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US7505931B2 (en) * 2003-03-03 2009-03-17 Standard Chartered (Ct) Plc Method and system for monitoring transactions
US7676034B1 (en) 2003-03-07 2010-03-09 Wai Wu Method and system for matching entities in an auction
US7587607B2 (en) * 2003-12-22 2009-09-08 Intel Corporation Attesting to platform configuration
US8037314B2 (en) * 2003-12-22 2011-10-11 Intel Corporation Replacing blinded authentication authority
CN1773905B (zh) * 2004-11-10 2010-08-18 日电（中国）有限公司 在安全通信系统中生成匿名公钥的方法、设备和系统
EP1838031A4 (de) * 2004-12-27 2013-08-14 Nec Corp System für begrenzte blindsignaturen
JP4872908B2 (ja) * 2005-02-10 2012-02-08 日本電気株式会社 メンバー証明書獲得装置、メンバー証明書発行装置、グループ署名装置、グループ署名検証装置
DE102005024609A1 (de) * 2005-05-25 2006-11-30 Siemens Ag Bestimmung einer modularen Inversen
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US8300798B1 (en) 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
WO2008065345A1 (en) * 2006-12-01 2008-06-05 David Irvine Cyber cash
US8566247B1 (en) 2007-02-19 2013-10-22 Robert H. Nagel System and method for secure communications involving an intermediary
US7958057B2 (en) * 2007-03-28 2011-06-07 King Fahd University Of Petroleum And Minerals Virtual account based new digital cash protocols with combined blind digital signature and pseudonym authentication
US7877331B2 (en) * 2007-09-06 2011-01-25 King Fahd University Of Petroleum & Minerals Token based new digital cash protocols with combined blind digital signature and pseudonym authentication
US7995196B1 (en) 2008-04-23 2011-08-09 Tracer Detection Technology Corp. Authentication method and system
US9087196B2 (en) 2010-12-24 2015-07-21 Intel Corporation Secure application attestation using dynamic measurement kernels
US9515824B2 (en) * 2013-10-21 2016-12-06 Aruba Networks, Inc. Provisioning devices for secure wireless local area networks
EP3215637B1 (de) 2014-11-03 2019-07-03 F. Hoffmann-La Roche AG Verfahren und biomarker zur vorhersage der effizienz der behandlung mit ox40 agonisten
US10013682B2 (en) 2015-02-13 2018-07-03 International Business Machines Corporation Storage and recovery of digital data based on social network
US9876646B2 (en) 2015-05-05 2018-01-23 ShoCard, Inc. User identification management system and method
WO2016179334A1 (en) 2015-05-05 2016-11-10 ShoCard, Inc. Identity management service using a block chain
US10587609B2 (en) 2016-03-04 2020-03-10 ShoCard, Inc. Method and system for authenticated login using static or dynamic codes
US10007826B2 (en) 2016-03-07 2018-06-26 ShoCard, Inc. Transferring data files using a series of visual codes
US10509932B2 (en) 2016-03-07 2019-12-17 ShoCard, Inc. Large data transfer using visual codes with feedback confirmation
EP3244360A1 (de) * 2016-05-12 2017-11-15 Skidata Ag Verfahren zur registrierung von geräten, insbesondere von zugangskontrollvorrichtungen oder bezahl- bzw. verkaufsautomaten bei einem server eines systems, welches mehrere derartige geräte umfasst
EP3560136B1 (de) * 2016-12-22 2020-12-02 Itext Group NV Verteiltes blockchain-basiertes verfahren zum speichern des orts einer datei
US10498541B2 (en) 2017-02-06 2019-12-03 ShocCard, Inc. Electronic identification verification methods and systems
USRE49968E1 (en) 2017-02-06 2024-05-14 Ping Identity Corporation Electronic identification verification methods and systems with storage of certification records to a side chain
EP4120620A1 (de) 2017-12-08 2023-01-18 Ping Identity Corporation Verfahren und systeme zur rückgewinnung von daten unter verwendung dynamischer passwörter
US11082221B2 (en) 2018-10-17 2021-08-03 Ping Identity Corporation Methods and systems for creating and recovering accounts using dynamic passwords
US10979227B2 (en) 2018-10-17 2021-04-13 Ping Identity Corporation Blockchain ID connect
DE102018009950A1 (de) * 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum Erhalten einer blinden Signatur
DE102018009943A1 (de) * 2018-12-18 2020-06-18 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum Erzeugen einer blinden Signatur
DE102019002731A1 (de) * 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
US11170130B1 (en) 2021-04-08 2021-11-09 Aster Key, LLC Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification
DE102021004025A1 (de) 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
DE102021004022A1 (de) 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Münzdepot-Verwaltungseinheit sowie Verfahren in einer Münzdepot-Verwaltungseinheit
DE102021005040A1 (de) 2021-09-24 2023-03-30 Giesecke+Devrient Advance52 Gmbh Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4759063A (en) * 1983-08-22 1988-07-19 Chaum David L Blind signature systems
WO1989008957A1 (en) * 1988-03-16 1989-09-21 David Chaum One-show blind signature systems
US4977595A (en) * 1989-04-03 1990-12-11 Nippon Telegraph And Telephone Corporation Method and apparatus for implementing electronic cash
US5224162A (en) * 1991-06-14 1993-06-29 Nippon Telegraph And Telephone Corporation Electronic cash system
NL9301348A (nl) * 1993-08-02 1995-03-01 Stefanus Alfonsus Brands Elektronisch betalingssysteem.
US5511121A (en) * 1994-02-23 1996-04-23 Bell Communications Research, Inc. Efficient electronic money
US5604805A (en) * 1994-02-28 1997-02-18 Brands; Stefanus A. Privacy-protected transfer of electronic information

Also Published As

Publication number Publication date
US5901229A (en) 1999-05-04
EP0772165A3 (de) 1998-08-26
EP0772165A2 (de) 1997-05-07
EP0772165B1 (de) 2004-08-25
DE69633217D1 (de) 2004-09-30

Similar Documents

Publication Publication Date Title
DE69633217T2 (de) Verfahren zum Implentieren von elektronischem Geld mit Hilfe einer Lizenz eines anonymen öffentlichen Schlüssels
DE69630738T2 (de) Verfahren und Einrichtung für ein elektronisches Geldsystem mit Ursprungserkennung
DE102017204536B3 (de) Ausstellen virtueller Dokumente in einer Blockchain
Sander et al. Auditable, anonymous electronic cash
DE19804054B4 (de) System zur Verifizierung von Datenkarten
DE69632482T2 (de) Elektronisches geldsystem ohne ursprungserkennung
DE60114833T2 (de) Überprüfbare, geheime mischung von verschlüsselten daten wie z. b. elgamal-verschlüsselte daten für gesicherte mehrinstanzwahlen
Magkos et al. Receipt-freeness in large-scale elections without untappable channels
DE102012206341B4 (de) Gemeinsame Verschlüsselung von Daten
Cramer et al. Improved privacy in wallets with observers
DE19781841C2 (de) Verfahren zum automatischen Entscheiden der Gültigkeit eines digitalen Dokuments von einer entfernten Stelle aus
DE112010004426B4 (de) Nicht verknüpfbare Übertragung ohne Gedächtnis mit Preisangaben und wiederaufladbaren Geldbörsen
DE69634715T2 (de) Verfahren und Einrichtung zur Erzeugung und Verwaltung eines geheimen Schlüssels eines Kryptosystems mit öffentlichem Schlüssel
DE19829643C2 (de) Verfahren und Vorrichtung zur Block-Verifikation mehrerer digitaler Signaturen und Speichermedium, auf dem das Verfahren gespeichert ist
DE102012005427A1 (de) Verfahren und System zur gesicherten Kommunikation zwischen einen RFID-Tag und einem Lesegerät
EP1368929B1 (de) Verfahren zur authentikation
WO2020212337A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem
de Solages et al. An efficient fair off-line electronic cash system with extensions to checks and wallets with observers
CH711133A2 (de) Protokoll zur Signaturerzeugung.
DE10143728A1 (de) Vorrichtung und Verfahren zum Berechnen eines Ergebnisses einer modularen Exponentiation
EP3899844A1 (de) Verfahren zum erzeugen einer blinden signatur
DE60202149T2 (de) Verfahren zur kryptographischen authentifizierung
Mambo et al. Unlinkable electronic coupon protocol with anonymity control
DE602004006373T2 (de) Verfahren und Vorrichtungen zur Erstellung fairer Blindunterschriften
EP3671602B1 (de) Verfahren zum direkten austausch eines münzdatensatzes zwischen sicherheitselementen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee