WO1996041316A2 - Off-line compatible electronic cash method and system - Google Patents

Off-line compatible electronic cash method and system Download PDF

Info

Publication number
WO1996041316A2
WO1996041316A2 PCT/US1996/010247 US9610247W WO9641316A2 WO 1996041316 A2 WO1996041316 A2 WO 1996041316A2 US 9610247 W US9610247 W US 9610247W WO 9641316 A2 WO9641316 A2 WO 9641316A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
electronic
coin
bank
transfer method
Prior art date
Application number
PCT/US1996/010247
Other languages
French (fr)
Other versions
WO1996041316A3 (en
Inventor
David W. Kravitz
Peter S. Gemmell
Ernest F. Brickell
Original Assignee
Kravitz David W
Gemmell Peter S
Brickell Ernest F
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 US08/474,035 external-priority patent/US5832089A/en
Application filed by Kravitz David W, Gemmell Peter S, Brickell Ernest F filed Critical Kravitz David W
Priority to AU67613/96A priority Critical patent/AU6761396A/en
Publication of WO1996041316A2 publication Critical patent/WO1996041316A2/en
Publication of WO1996041316A3 publication Critical patent/WO1996041316A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme

Definitions

  • This invention relates to the field of electronic transactions and, in particular, to the field of electronic transactions related to electronic cash.
  • Electronic cash is a subject of great economic, political and research importance. With advances in computer networks, processor speed and databases, electronic cash systems and methods are likely to become widespread within five to ten years. Other factors likely to lead to more widespread use of electronic cash systems and methods are advances in note counterfeiting technology and the desire of both individuals and businesses for remote and more convenient financial transactions. Electronic cash systems and methods meeting these needs must make a trade-off between privacy and a number of other considerations.
  • a blind signature scheme such as the one taught by Chaum in the above-referenced article is a protocol in which the signer signs a piece of information for a user without being aware of the message for which it is providing a signature.
  • the signer may be a bank or a minting facility.
  • the recipient of the signature in this scheme does not learn anything from the protocol which would enable this user to sign other information.
  • This type of signature scheme when used in the context of electronic cash, enables the user of these systems to withdraw money from the bank and spend it with a payee. Furthermore, the payer in these systems may be confident that when the payee deposits the money at the bank, the bank is not able to recognize the money as the same cash withdrawn by the payer.
  • the bank when electronic coins are deposited by a payee with the issuing bank, the bank would like to be able to determine that the coin is not overspent or counterfeit. In order to do this it is known for the bank to maintain exhaustive lists of the coins which it has issued. Upon receiving a deposit of an electronic coin the bank may compare the received deposit with the list of issued coins. If the received coin is on the list and is not overspent, the bank may make payment on it.
  • the Medvinsky-Neuman system provides a payee-coin to prevent over-spending by a user.
  • the payee-coin is only accepted by a designated payee since only the designated payee can prove to the server that it holds a valid coin.
  • the user cannot convert the payee-coin to another coin and later accept a receipt for unpaid merchandise.
  • the payee- coin may incorporate a one-time public key chosen by the payee. However, the resulting receipt is meaningless in this system because it is not associated with the actual payee in an adjudicatable manner.
  • a payor-coin is also provided in the system of Medvinsky and Neuman.
  • the payor-coin prevents someone other than the payor from spending the coin or receiving a receipt for merchandise. Even the cash server cannot spend the payor-coin.
  • the public key used with the payor-coin can be chosen for an individual coin by the payor when the payor purchases the coin. This protects the identity of the payor from the payee when later presenting the receipt . It also protects the identity of the payor from the server when purchasing a coin with another anonymous coin.
  • This Chaum system also has rather complex coding requirements. A large amount of computation is required by the user. For example, in order to withdraw one non-fungible coin a user must perform at least ten modular exponentiations involving a base and exponent that are numbers of about 800 bits each. Additionally, the application of a one-way hash function is also required in this system. A withdrawal of $100 that is fungible would require at least one hundred applications of one-way hash functions. It is desirable that code speeds which are significantly higher than this be available if the system is to be convenient to use.
  • a single coin may be represented by at least seven numbers of about 800 bits each. Thus a single coin may require at least 5600 bits. Due to the lack of fungibility, several coins of this size may be required to meet the needs of the user which may be met by a single more fungible coin.
  • the space required by the coins is important to both the user and the banks. High storage requirements for the user may limit the ability of the user to benefit from the system. High storage requirements for the bank may mean, among other things, that searches to determine overspending of electronic coins are slower. The same factors leading to large space requirements cause a taxing of the communication bandwidth available to users of the system.
  • the banks are unable to differentiate between electronic coins that are legitimately withdrawn from the bank and coins created by criminals using the minting key. As long as the value of forged coins remains low relative to the amount of legitimate money in circulation, the banks are unable to determine that there is a problem. Even if the value of the forged coins that are deposited becomes high, the bank may only be aware that some unknown party has created forged coins . It may still be unable to distinguish between them and legitimate coins.
  • An off-line electronic cash system having an electronic coin, a bank B , a payee S, and a user U with an account at the bank B as well as a user password Z u,i, is provided with method for performing an electronic cash transfer.
  • an electronic coin is withdrawn from the bank B by the user U and an electronic record of the electronic coin is stored by the bank B.
  • the electronic coin is paid to the payee S by the user U and the payee S deposits the electronic coin with the bank B.
  • a determination is made that the electronic coin is spent in accordance with the deposit and the record of the electronic coin is deleted by the bank B in response thereto.
  • a further deposit of the same electronic coin after the electronic record is deleted is determined. Additionally, a determination may be made which user U originally withdrew the electronic coin after the record is deleted.
  • Fig. 1 is a flow chart representation of a setup protocol suitable for use in the electronic cash system and method of the present invention
  • Fig. 2 is a flow chart representation of an electronic cash withdrawal protocol suitable for use in the electronic cash system and method of the present invention
  • Fig. 3 is a flow chart representation of an electronic payment protocol suitable for use in the electronic cash system and method of the present invention
  • Fig. 4 is a flow chart representation of an electronic deposit protocol suitable for use in the electronic cash system and method of the present invention
  • Fig. 5 is a flow chart representation of an electronic withdrawal protocol adapted for use with a designated payee within the electronic cash system and method of the present invention
  • Fig. 6 is a flow chart representation of an electronic payment protocol adapted for use only with a designated payee within the electronic cash system and method of the present invention
  • Fig. 7 is a flow chart representation of an electronic withdrawal protocol adapted to permit tracing of a user by encoding information within the electronic coin within the electronic cash system and method of the present invention
  • Fig. 8 is a flow chart representation of an electronic payment protocol adapted to permit a payee to identify a minting bank suitable for use with a plurality of banks within the electronic cash system and method of the present invention
  • Fig. 9 is a flow chart representation of an electronic deposit protocol adapted for use with the electronic payment protocol of Fig. 8 within the electronic cash system and method of the present invention
  • Fig. 10 is a flow chart representation of an electronic setup protocol suitable for use with a trustee system within the electronic cash system and method of the present invention
  • Fig. 11 is a flow chart representation of an electronic withdrawal protocol adapted for use with the protocol of Fig. 10 within the electronic cash system and method of the present invention
  • Fig. 12 is a flow chart representation of an electronic withdrawal protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention
  • Fig. 13 is a flow chart representation of an electronic payment protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention
  • Fig. 14 is a flow chart representation of an electronic deposit protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention
  • Fig. 15 is a flow chart representation of an electronic transfer protocol for transferring electronic cash from a payee to a third party suitable for use within the electronic cash system and method of the present invention.
  • Fig. 16 is a flow chart representation of an electronic deposit protocol suitable for use by a third party and suitable for use within the electronic cash system and method of the present invention.
  • Fig. 1 the electronic cash setup protocol 100 for use in a presently preferred embodiment of an electronic cash system in accordance with the present invention.
  • a financial-based transaction system is shown and described herein the present invention is not limited to financial-based transaction systems.
  • the present invention encompasses other non-financial transaction systems including, but not limited to, identification or access control systems and voting systems.
  • all values which are digitally signed in the present invention are preprocessed in the system and method of the present invention using appropriate redundancy and/or one-way hash functions in a manner understood by those skilled in the art.
  • both the messages and their digital signatures are transmitted in the instant description, it will be understood that in some cases this may be unnecessary. For example, it is not necessary to transmit both a message and its digital signature when the message is recoverable from its digital signature.
  • the user U is any user entity which later withdraws and spends electronic cash and the bank B is any bank or other entity from which the user U withdraws the electronic cash.
  • the seller S or payee S is any seller or payee entity which receives the electronic cash from the user 17 and deposits the received electronic cash at a bank entity such as the bank B in later protocols described hereinbelow. It is assumed in the electronic cash setup protocol 100 that the user U and the bank B have a line of secure private communication for the proper functioning of the later withdrawal procedure described hereinbelow. This feature is important in order to minimize the use of encryption within the system of the present invention and thereby avoid the computation requirements associated with encryption. As described in detail hereinbelow the secrecy of the public signature key of the user U is relied upon to keep transactions of the user U anonymous in the present invention.
  • the user U of the electronic cash system of the present invention obtains the required software and provides a user identification to the bank B as shown in block 104.
  • the bank B provides a system identification, account_number u , to the user U as shown in block 108.
  • the system identification account _number u of block 108 may later be used in the anti-fraud operations of the electronic cash system if the user U attempts to overspend the electronic cash withdrawn from the bank B.
  • the system identification value, account_number u, transmitted in block 108 may also serve as the bank account number of the user U.
  • the bank B also provides the user U with the bank public signature key signP B .
  • the public signature key signP B may also be provided to the user U by the software the user U acquires.
  • the value of signP B transmitted by the bank B in block 108 may be used later to verify that the information had been signed by the bank B.
  • the user U may use the public signature key signP B to identify the bank B and to verify messages transmitted by the bank B .
  • the public signature key signP B is verified by the user U by comparing it with the public signature key signP' B .
  • the public signature key signP' B is received by the user U in the software of block 104. If the public signature key signP' B of the bank B is verified in this manner, the user U sends its own public signature key, signP u .
  • the public signature key signP B of the user U corresponds to the secret key, sign s u , of the user U which is also received by the user U in the software of block 104 or is generated using such software.
  • This transmission of its public signature key signup by the user U is shown in block 116 of the setup protocol 100.
  • the bank B stores the identification of the user U, account_number u , and signP u into its database.
  • the electronic cash withdrawal protocol 200 is a method for permitting the user U to withdraw electronic cash from the bank B.
  • the preferred embodiment of the electronic cash system and method of the present invention is based upon electronic coins which are represented, at least in part, by digital signature key pairs.
  • the electronic coins are of the form (coin_sign P , coin_sign s ) wherein the key coin_signP is a public coin signing key of the user U.
  • the key coin_sign s is a secret coin signing key of the user U corresponding to the public coin signing key coin_signP.
  • the user U which is withdrawing an electronic coin from the bank B randomly or pseudorandomly generates a digital signature key pair ⁇ coin_signP, coin_sign s ) as shown in block 204.
  • a digital signature key pair ⁇ coin_signP, coin_sign s
  • any known method of providing digital signature key pairs may be used.
  • the Digital Signature Standard, DSS, or RSA may be used to generate the signature key pairs of block 204.
  • the user 17 transmits a copy of the public key coin_signP, its user password z u, i , and withdrawal_value to the bank B. It will be understood that withdrawal_value is the amount of electronic cash that the user U wishes to withdraw from the bank B.
  • the values transmitted by the user U in block 208 are signed by the user U with the long-term user secret key sign s u . In order to ensure that no one else can spend the electronic coin being withdrawn the user 17 never reveals the secret key coin_sign s .
  • the bank B maintains lists of all electronic coins withdrawn and all electronic coins deposited.
  • the bank B can therefore check that no legitimate electronic coin is being spent beyond the maximum value, withdrawal_value, transmitted in block 208. Using these lists the bank B can also determine that no counterfeit coins are being introduced into the system in case the signature key of the bank B is compromised.
  • embodiments of the present invention maintaining lists of this type require a large amount of computer memory storage in order to maintain records of all such electronic coins.
  • the bank B identifies the user U by looking up the user password z u ,i in its database.
  • the bank B verifies the user transmissions of block 208.
  • the user password z u ,i is an indexed password. Therefore, as shown in block 220, the bank B independently computes the next value of the user password, z u,i+1 , and deducts the amount of the withdrawal from the bank account of the user U.
  • the bank B signs the public key coin_signP as well as the coin value withdrawal_value as shown in block 224 using its secret key sign s B . This permits the payee S to recognize the electronic coin as valid currency with a maximum value withdrawal_value when it receives the coin from the user 17.
  • the user U verifies the transmission of block 224 using signP B .
  • the user 17 updates the user password z u ,i to obtain the next password z u,i+l as shown in block 232 independently of the bank B.
  • Fig. 3 there is shown the electronic cash payment protocol 300 of the present invention.
  • the payee S Prior to payment of the electronic cash amount payment_value to a payee S by the user 17 the payee S sends a value, counter, as a challenge to the user U.
  • the payee challenge is shown in block 304 of the payment protocol 300.
  • counter is also updated by the payee S after transmission to the user U in order to provide a unique value for each challenge.
  • the purpose of the challenge by the payee S is to prevent replay attacks wherein a user U can resend a transaction to a payee S or wherein a payee S can resend a transaction to a bank B.
  • Another attack prevented by the payee challenge of block 304 could come from an eavesdropper who could try to replay the same conversation with the payee S to illegally acquire goods from the payee S .
  • the eavesdropper in this case may operate without the knowledge of the user U.
  • the user U uses its secret value of coin_sign s to compute coin_sign s ⁇ payment_value, S, counter), wherein S in this context is understood to be an identification of the payee S .
  • the user U sends the values of wi thdrawal_value and coin_signP as well as a partial representation of the electronic coin sign s B ( coin_signP, wi thdrawal_value) signed by the bank B to the payee S .
  • the user U also sends the signed electronic coin payment computed in block 312, coin_sign s ⁇ payment_value, S, counte ), which is computed over the transaction amount, the identification of the payee S , and the challenge received from the payee S .
  • the payee S verifies the signature of the bank B on the public part of the electronic coin and in block 324 the payee S verifies the signature of the payment of the coin.
  • Fig. 4 there is shown the electronic cash deposit protocol 400 of the present invention.
  • the payee S which received an electronic payment from the user U sends a transcript of the transaction as set forth in the payment protocol 300 to the bank B.
  • the bank B verifies that the value of the challenge counter, represented as counter, used by the payee S is correct by comparing it with its own copy, counter s B , as shown in block 408.
  • the bank B verifies part of the transmission of block 316 by determining that the payment of the amount payment_value was made to the payee S with the challenge counter using the coin corresponding to the secret coin signing key coin_sign s .
  • the bank B determines that ( coin_signP, wi thdrawal_value) was used in a legitimate withdrawal such as a withdrawal as set forth in the electronic cash withdrawal protocol 200 hereinabove.
  • the bank B also verifies that the sum of the deposits using ( co in_s ignP, wi thdrawal _value) does not exceed the value withdrawn as shown in block 420.
  • the appropriate account of the depositor is adjusted to reflect the deposit made using the deposit protocol 400. Referring now to Fig. 5, there is shown the designated payee withdrawal protocol 500 of the method and system of the present invention.
  • the designated payee withdrawal protocol 500 may be used when a user U wants to make a purchase in such a way that the payee S can be assured without conferring with the bank B that the electronic cash used in the purchase is not overspent.
  • the designated payee withdrawal protocol 500 requires the identity of the payee S to be encoded or embedded in an electronic coin withdrawn from the bank B and signed by the bank B. Payments involving electronic cash obtained using the withdrawal protocol 500 are then only valid with the designated payee S . Therefore the electronic coin may be referred to as a directed electronic coin.
  • the setup protocol required prior to the operation of the designated payee withdrawal protocol 500 may be the same as the electronic cash setup protocol 100 used in connection with the withdrawal protocol 200 wherein the electronic cash withdrawn could be used with any payee S.
  • the user U withdrawing an electronic coin from the bank B randomly generates a digital signature key pair ( coin_signP, coin_sign s ) as shown in block 504.
  • a digital signature key pair coin_signP, coin_sign s
  • any known method of providing digital signature key pairs may be used in block 504 to generate a digital signature key pair as previously described with respect to block 204.
  • DSA may be used.
  • the user 17 transmits the user password z u ,i , a copy of the public key coin_ sign P , wi thdrawal_value and the value S which is a representation of the payee S .
  • the value wi thdrawal _value is the amount of electronic cash the user U wishes to withdraw from the bank B. It will be understood that it is the inclusion of the identification of the payee S within the electronic coin in the manner set forth in block 508 that creates the ability to provide a designated payee electronic coin.
  • the values transmitted by the user 17 in block 508, including the representation of the designated payee S are signed by the user U using the user secret key, sign s u . In order to ensure that no one else can spend the electronic coin being withdrawn the user U never reveals the secret key coin_sign s .
  • the bank B identifies the user U by looking up the user password z u ,i in its database. In block 516 the bank B verifies the user transmissions of block 508. In the preferred embodiment of the invention the user password z u ,i is an indexed password. Therefore, as shown in block 520, the bank B independently computes the next value of the user password, z u,i+1 . The bank B then deducts the amount of the withdrawal from the bank account of the user U. The bank B signs the public key coin_signP as well as the value of the electronic coin wi thdrawal_value and the representation of the designated payee S as shown in block 524.
  • the signing of these values by the bank B is performed using its secret key sign s B so that the payee S can recognize the electronic coin as valid currency when it receives the electronic coin from the user 17.
  • the user U verifies the transmission of block 224 using signP B .
  • the user U updates the user password z u ,j to obtain the next user password z u ,i+1 as shown in block 232.
  • the update performed by the user U in block 232 is independent of the bank B. It will be understood by those skilled in the art that in the electronic cash withdrawal protocol 500 all messages may be sent in the clear and that the user U may thus identify itself to the bank B without using encryption.
  • a payee S can be certain that the user 17 has not used an electronic coin received from the user U to pay anyone else.
  • the designated payee payment protocol 600 may be used in cooperation with the designated payee withdrawal protocol 500.
  • the deposit protocol required in connection with the designated payee payment protocol 600 may be similar to the basic electronic cash deposit protocol 400 described hereinabove except that in the designated payment protocol 600 the bank B verifies that the payee S of the directed payment is the same as the payee S which is encoded or embedded within the electronic coin.
  • the payee S Prior to payment of the electronic cash amount payment_value to a payee S by a user 17 the payee S sends a value, counter, to the user U as a payee challenge.
  • the payee challenge is shown in block 604 of the designated payee payment protocol 600 wherein the challenge counter is updated by the payee S after transmission to the user 17.
  • the purpose of the payee challenge is to prevent replay attacks wherein a user U can resend a transaction to a payee S .
  • Another type of replay attack prevented by the payee challenge is one in which a payee S can resend a transaction to a bank B.
  • a further attack prevented by the payee challenge of block 604 could come from an eavesdropper who could try to replay the same conversation with the payee S to illegally acquire goods from the payee S .
  • Such an eavesdropper may operate without the knowledge of the user U.
  • the user U uses its secret value of coin_sign s to compute part of the transmission, coin_sign s ⁇ payment _value, S , counter) .
  • S is an identification of the designated seller S or payee S as previously described with respect to the designated payee withdrawal protocol 500.
  • the user U sends the signed value of block 612 as well as a partial representation of the electronic coin sign s B ( coin_signP, wi thdrawal_value, S') signed by the bank B to the payee S .
  • the user U also sends the signature of the coin, coin_sign s ⁇ payment_value, S , counter) which includes the transaction amount, the identification of the payee S and the challenge received from the payee S .
  • the payee S verifies the signature of the bank B on the public part of the electronic coin and in block 624 the payee S verifies the signature of the electronic coin received from the user U during the purchase.
  • the bank verifies that the payee S has not received more than wi thdrawal_value, for the coin in block 628.
  • Fig. 7 there is shown the electronic cash withdrawal protocol 700.
  • the electronic cash withdrawal protocol 700 is adapted to minimize the record keeping required by a bank B while permitting the bank B to control overspending and fraud. This and other objectives are realized by permitting the bank B to encode or embed predetermined information about a user U within an electronic coin withdrawn using the withdrawal protocol 700. By encoding information within an electronic coin as set forth in the withdrawal protocol 700 the bank B and no one else can trace the user C7 which withdraws the electronic coins.
  • the bank B can perform the tracing of electronic coins without retaining records of spent coins indefinitely.
  • the full value of a legitimate electronic coin minted using the electronic cash withdrawal protocol 700 may be deleted from the bank database and the bank B must maintain only a list of the currently circulating legitimate electronic coins.
  • the ability to delete records of spent electronic coins greatly reduces the storage requirements for the bank B.
  • the complicity of the identified user U may be verified through its signature sign s u ⁇ coin_signP, withdrawal_value,&).
  • the user 17 transmits a copy of the public key coin_signP, its user password Z u , i , and withdrawal_value . It will be understood that wi thdrawal value is the amount of electronic cash the user U wishes to withdraw from the bank B.
  • the values transmitted by the user U in block 708 are signed by the user U with the user secret key, sign s u . In order to ensure that no one else can spend the electronic coin being withdrawn the user U never reveals the secret key coin_sign s .
  • the bank B identifies the user U by looking up the user password z u ,i in its database. In block 716 the bank B verifies the user transmissions of block 708.
  • the user password z u ,i is an indexed password. Therefore, as shown in block 720, the bank B independently computes the next value of the user password, z u,i+1 , and then deducts the amount of the withdrawal from the bank account of the user U.
  • the bank B signs the public key coin_signP as well as the electronic coin value withdrawal_value as shown in block 724 using its secret key sign s B . In this manner the payee S can recognize the electronic coin as valid currency when it receives the coin from the user U.
  • the user U sends its signed values to the bank B.
  • the bank verifies the transmission of block 728 in block 732.
  • the bank B appends the values transmitted in block 708 using its secret key signP B , signs the public key coin_signP of the user U, the withdrawal value, the hash operation of block 724 and the signed transmission transmitted from the user U in block 726.
  • the signed value set forth in block 736 is transmitted to the user U in block 740.
  • the user U verifies this transmission in block 744 and updates the user password z u ,i to obtain z u, i +1 as shown in block 748 independently of the bank B.
  • the two multibank electronic cash protocols 800, 900 may be used in the electronic cash system and method of the present invention when a plurality of banks are involved in an electronic cash transaction.
  • the user 17 is any user entity which withdraws and spends electronic cash, as described previously, and the payee a is any seller or payee entity which receives and deposits the electronic cash received from the user U.
  • the bank B u is a bank wherein the user U has a bank account and the bank B s is a bank wherein the payee S has a bank account.
  • the user U may perform a basic setup protocol as set forth in the electronic cash setup protocol 100 described hereinabove. Additionally, the withdrawal protocol performed by the user U under these circumstances may be substantially the same as that set forth in the electronic cash withdrawal protocol 200 described hereinabove.
  • the minting key, sign s Bu of the bank B u in the multibank protocols 800, 900 may be different from the minting keys of other banks.
  • the multibank payment protocol 800 may be substantially similar to the electronic cash payment protocol 300 described hereinabove except that in the multibank case the user U identifies the bank B u that minted the electronic coin so that the payee S may use the correct bank public key to verify the validity of the electronic coin it receives.
  • the payee S selects a random value ⁇ s and sends it, along with the challenge counter, counter, to the user 17 as shown in block 804.
  • the user U increments the counter.
  • this protects the anonymity of the payee S from the issuing bank B u of the user U if the bank B u is different from the bank B s where the payee S deposits the coin.
  • the user U then signs the payment value and the value computed in block 808 using the key coin_sign s as shown in block 812.
  • the payee S may already know the public signing key of the issuing bank B u . If not the user U may send that key also. An expiration date may also be provided by the user U. If the user U sends the signing key in this manner it must be certified by an independent authority. As shown in block 816 the user U sends the value computed in block 812 along with a signed signal including its public key, coin-signP, the withdrawal value, wi thdrawal_value, and the identity of the bank B u . In blocks 820, 824 the payee S verifies the transmissions of block 816 within the multibank electronic cash payment protocol 800.
  • the payee S sends the random value ⁇ s to its own bank B s as shown in block 904.
  • the role previously performed by the single bank B is then divided between the bank B s of the depositor and the bank B u that issued the electronic coin exchanged by the user U and the payee S These operations are set forth in blocks 908-928.
  • the value P s H( ⁇ s , counter s Bs , S) is computed by the bank B s in block 908 and the transmission of block 904 is verified in block 912.
  • the bank B u then transmits to the bank B u as shown in block 916.
  • bank B verifies that the payee S is the intended recipient of the electronic com and that the payee S has not made the same deposit before.
  • the bank B u also verifies that the electronic coin has not been overspent and that it is not counterfeit.
  • the bank B u then credits the bank B s in block 928 for the amount payment_value if all verifications of blocks 920, 924 are performed correctly.
  • the bank B s then credits the payee S for amount payment_value within the multibank electronic cash deposit protocol 900.
  • the trustee-based tracing setup protocol 1000 In the trustee-based tracing setup protocol 1000 only one of the trustees, for example the bank B, needs the power to mint or coin electronic money.
  • the bank A may be a bank without the power to mint electronic coins in the protocol 1000.
  • the entities described as bank A and bank B in the instant embodiment need not be banks in alternate embodiments of the present invention.
  • the user U acquires the required software as previously described in block 104 of the electronic cash setup protocol 100.
  • the user 17 also sends its identification to the bank A in block 1004.
  • the bank A later anonymously sends to the minting bank B all the information the bank B requires to sign the coin withdrawn by the user U.
  • the bank A may act as a courier that is not able to determine which coins the user U and the bank B are communicating.
  • the bank A sends the account number of the user U to the user U in block 1008 and the user U sends its public signature key, signP u , to the bank A in block 1012.
  • the bank A puts the identification of the user U, the account number and public key into its database as shown in block 1016 and sends the bank public signature key, signP B , to the user 17 in block 1020.
  • the user U may generate any number of encryption key pairs and generate any number of electronic coins as shown in blocks 1024, 1028.
  • the withdrawal values, along with the public keys of block 1024 and electronic coins encrypted with the public encryption key of the bank B, are then sent to the bank A as shown in block 1032.
  • the withdrawal values, the p values, the encryption keys, and the encrypted electronic coins are sent to the bank B as shown in block 1036.
  • the bank B decrypts to recover coin_sign P K as shown in block 1040 and sends the coins to the bank A as shown in block 1044 of the trustee-based tracing setup protocol 1000
  • the trustee-based withdrawal protocol 1100 there is shown the trustee-based withdrawal protocol 1100.
  • the user U sends a request for a withdrawal and a value K to a courier bank A as shown in block 1104.
  • the courier bank A then deducts the withdrawal value associated with k, wi thdrawal_value K , from the account which the user 17 has previously opened as shown in block 1108.
  • the courier bank A also sends encrypt p uK ( sign s B ( coin_sign P K , wi thdrawal_value k , ⁇ K B ), sign S B
  • the protocols used for payment and deposit in connection with the trustee-based tracing of the system of the present invention may be similar to the electronic cash payment protocol 300 and the electronic cash deposit protocol 400 as set forth hereinabove.
  • the courier bank A and the bank B may use a combination of hashing with secret keys and identification of the user U in order to be able to trace the electronic coin back to the user U. They do so in such a way as to be able to prove that the electronic coin being traced was issued to the user U without weakening the anonymity of other coins in the system.
  • Figs. 12, 13, 14, there are shown the anonymous transfer withdrawal protocol 1200, the anonymous transfer payment protocol 1300 and the anonymous deposit protocol 1400.
  • the concept of tokens used in the anonymous transfer protocols 1200, 1300 and 1400 to enable transferability is disclosed in more detail in D. Chaum and T. P. Pedersen, "Transferred Cash Grows in Size,” Advances in Cryptology - Proceedings of Eurocrypt 92, (1993), pp. 390-407.
  • the setup phase required to use the anonymous transfer protocols 1200, 1300 and 1400 may be the same as that previously described with respect to the electronic cash setup protocol 100 except that the user U in the anonymous transfer protocols 1200, 1300 and 1400 learns the public encryption key, encryptP B , of the bank B.
  • the first type of withdrawal is withdrawal of an ordinary electronic coin with a cash value withdrawal_value.
  • the method for performing this type of withdrawal is substantially similar to that set forth hereinabove with respect to the electronic cash withdrawal protocol 200.
  • the other type of anonymous withdrawal is withdrawal of a transfer token, ( token_signP, token_sign s ), sign_token s B , ( token_signP), for use in receiving payments and transferring ordinary electronic coins by a party which is paid in one transaction and wishes to use the electronic coins to pay another entity.
  • a transfer token ( token_signP, token_sign s ), sign_token s B , ( token_signP)
  • the transfer tokens of the anonymous transfer protocols 1200, 1300 have no inherent cash value. If the transferrer of the electronic coin of anonymous tranfer protocols 1200, 1300 attempts to overspend a transferred electronic coin the bank B can use the public part of the transfer token to identify the culprit.
  • token_signP (token_signP, token_sign s ) is generated in block 1204.
  • the user U sends to the bank B the user password,
  • the bank B identifies the user U using the password z u i and verifies the signed transmission of block 1208 as set forth in blocks 1212, 1216.
  • the bank B independently computes the next value of the user password z u,i +1 and sends the public key of the user U back to the user U signed by the secret key of the bank B as shown in block 1220.
  • the user U verifies the signed transmission of block 1220.
  • the user U independently computes the next password, z u,i+1, in block 1228.
  • the withdrawal protocol required for this procedure is similar to the withdrawal protocol 200 with a few important differences.
  • the payee S chooses a random value ⁇ s as shown in block 1304.
  • the payee S sends p s and token_signP as part of a challenge to the user U in block 1312.
  • the purpose of this challenge by the payee S is to prevent replay attacks and to confirm to a bank B s used by the payee S that the payee S is the recipient of the payment.
  • the payee S then increments its counter in block 1312.
  • the reason the value counter and the identity of the payee S are hidden is so that the recipient v of a further transfer of the electronic cash cannot identify the payee S .
  • the user U and the payee S use an authenticated key exchange protocol to agree on a mutual secret encryption key prior to performing the anonymous transfer payment protocol 1300. They then communicate the payment process in private so that eavesdroppers can not recognize the signing keys coin_signP, token_signP if they later appear in other transfer protocols performed in accordance with the present invention.
  • the bank B verifies the payment protocol and ⁇ ⁇ as shown in blocks 1408, 1412.
  • the bank B increments its counter and verifies that the withdrawal is legitimate in block 1416.
  • the bank B also verifies that the electronic coin being deposited is not overspent as shown in block 1420.
  • the anonymous transfer protocol 1500 may be used to permit the anonymous transfer of an electronic coin from a payee S to a third party N in the electronic cash system of the present invention.
  • the transfer of a previously spent electronic coin in the transfer protocol 1500 is similar to the first payment of an electronic coin protocol set forth in the anonymous transfer electronic cash payment protocol 1300 and others described hereinabove.
  • random value ⁇ v is generated as shown block 1504.
  • a value of ⁇ ⁇ is determined in block 1508.
  • the value ⁇ ⁇ and a token are sent to the payee S in block 1512.
  • the payee S computes and uses a token in place of a regular electronic coin as shown in block 1516.
  • the payee S then appends information from the third party M and transmits to the third party M in block 1520.
  • the third party M then performs the verifications of blocks 1528-1540 of anonymous transfer protocol 1500.
  • the anonymous deposit protocol 1600 may be used to deposit an electronic coin which was anonymously transferred according to the anonymous transfer protocol 1500.
  • the third party M transmits to the bank B a record of the anonymous payment and the random value ⁇ v , as shown in block 1604.
  • the bank B then verifies that the transfer protocol 1500 was executed properly by the payee S as shown in block 1608.
  • the bank B determines that the electronic cash was not overspent.
  • this feature of the present invention may be understood to be an improvement of the protocols of Brands which allows for trustee-based tracing. There is no need for any tamper-resistant devices or any inconvenience to the user U in this method. The security of all parties in this method is based only upon cryptographic assumptions. Trustees T 1 and T 2 participate in an interactive process during the setup protocol when they conduct proofs of knowledge of a representation for each value f k wherein k indexes the electronic coin withdrawn by the user U and each electronic coin is understood to have a different value f K .
  • p, q be large primes such that g
  • g, g 1 , -g 2 , g 3 , g 4 , d be generators of ⁇ randomly chosen by the bank B.
  • the setup, withdrawal, and payment protocols are extensions of basic setup, withdrawal and payment protocols taught by Brands.
  • the user U gives the trustees T 1 and T 2 information which allows them to link any payment involving each electronic coin to its withdrawal.
  • the trustees T 1 and T 2 prove to the government G that they know the representation for this value of f k .
  • the trustees T 1 and T 2 prove combined knowledge of a representation of f k to the bank B relative to g 3 and g 4 .
  • the underlying idea of the protocol of Brand is that the bank B provides the user 17 with a blind signature that is a tuple (A,B,z',a'b',r') .
  • H is a one-way collision-free hash function, it is believed to be hard to create a tuple of this form without finding the discrete log of h .
  • the features of Brands referred to may be found, in particular, in S.
  • the payee S then verifies that AB ⁇ 1 and sign ⁇ (A, B) .
  • the payee S sends a transcript of the payment protocol to both the bank B and the government G.
  • the procedure which the government G can use to trace multiple spenders is substantially similar to that set forth in the basic protocols of Brands .
  • the bank B has records of an electronic coin spent two times, with two different challenges, ⁇ , ⁇ ' .
  • the bank B uses the two sets of responses (r 1 , r 2 , r 3 ) and (r' 1 ,r' 2 ,r' 3 ) and computes
  • I u g 1 u1 g 2 u2 .
  • the government G asks the trustees T 1 and T 2 for all sets of withdrawal values ⁇ s i,j ⁇ i,j ⁇ 1,2 ⁇ for the user U.
  • the trustees T 1 and T 2 attempt to prove combined knowledge of a representation of l u df k relative to m' (r3(-1)mod(q)) using their knowledge of s k 1, 1 and s k 1,2 . If the trustees T 1 and T 2 succeed, the government G assumes that the electronic coin involving m' was spent by the user U.
  • the inventive method includes a solution which guarantees the innocent user U at least notification that it is being traced even if the government G and all human trustees T 1 and T 2 conspire against the user 17.
  • This solution includes an electronic trustee T E in which both the government G and the user U may feel confident in placing their faith.
  • the trustee system set forth is described in terms of electronic cash. However, it will be understood by those skilled in the art that similar trustees may be used in the context of other types of key-escrow systems.
  • Another requirement is that the government G needs to be certain that it can access each share of the key of the user U as held by an electronic trustee T E .
  • a solution to this problem requires both parties to build separately a different part of a two- part electronic trustee.
  • the government may build an inner part of the electronic trustee T E without knowledge of the eventual user U corresponding to the electronic trustee T E .
  • This part should be read-proof against the user 17.
  • the entire inner part may be embedded in the latest high-tech tamper-resistant material. By read-proof it is intended that the user U cannot alter any component of the inner part without erasing the secret signature key, Sig S T , of the inner part and that the user U cannot read the value of Sig s T .
  • the government G extracts the corresponding value of SigP T from the inner part prior to surrendering control of the inner part to the user U.
  • the inner part accepts as input the private key ⁇ T corresponding to the trustee public key E-p into a register which can be loaded exactly once by the outer part and is non-erasable but readable. This is the register which the government G needs to read from each electronic trustee T E to enable a trace of spending by the user U.
  • a register which the government G needs to read from each electronic trustee T E to enable a trace of spending by the user U.
  • the outer part of the electronic trustee T E monitors the output of the Sig s T function and controls the transmissions of the electronic trustee T E in order to eliminate leakage with respect to the value of ⁇ T .
  • the outer part In order to electronically notify the user U if an attempt has been made to recover the value of ⁇ T from the electronic trustee T E , while protecting the government G from false claims of unauthorized access to ⁇ T , the following procedure is specified.
  • the outer part generates a pulse key pair, (Kpulse T s , Kpulse T p ), where the public key Kpulse T P is registered with a third party prior to deployment of the electronic trustee T E .
  • se T s is used to sign periodic sequenced messages, verifiable using Kpulse T p , which effectively affirms that no attempt has been made to retrieve ⁇ -p, since the user 17 can implement the outer part so that Kpulse T s is automatically erased upon intrusion of the electronic trustee T E .
  • the electronic trustee T E is coated under user and government supervision. It is in the legitimate interest of the user U to apply a coating which alters upon tampering and is impossible to reproduce exactly or to predetermine. The government G assures itself that the outer part and the coating are constructed so that the coating cannot be modified spontaneously or from within.
  • a digitization of the coating is signed by the Kpulse T S key of the outer part. The user U can design and implement the Kpulse T S function so as to thereafter accept only internally generated inputs. Alternatively, the digitized value of the coating is signed by the user 17 or its legal representative. The signed version of the coating value is supplied to the government G.
  • the electronic trustee T E is from then on, held securely under government control.
  • the following addresses the problem of the user U wishing to make an anonymous purchase from a payee S but having incorrect change. It is assumed that the payee S in this system has a computer link to a bank B but that the user U does not wish to identify itself to the bank B in order to prevent the bank B form associating it with the payee S . It is also assumed that the user U has Y dollars in coins and that the user U wishes to make a purchase worth X ⁇ Y dollars.
  • a protocol is therefore presented hereinbelow which allows a user U to present anonymously a set of electronic coins worth Y dollars to the bank B and receive in return another set of electronic coins also worth Y dollars but in different denominations.
  • the user U chooses the denominations in such a way that it can combine the returned electronic coins to get X dollars.
  • the user 17 When getting anonymous change the user 17 wishes to give the bank B an amount equal to Y dollars in coins of different denominations.
  • the user 17 uses the payment protocol to pay the y dollars in electronic coins to the bank B without revealing ID u and tells the bank B the desired denominations of the change.
  • the above protocol when added to either the basic protocols of Brands or to the trustee-based system, maintains the following properties.
  • the augmented system is secure against counterfeiting and multiple spending by a user U. Without help from all the trustees, the values appearing in the payments of electronic coins transmitted by the user U are completely independent from the values appearing in the withdrawals. The trustees may then combine their information and trace both the original coins of the user U and the coins given as change.
  • the Digital Signature Algorithm Unlike prior art RSA signature schemes, the Digital Signature Algorithm, as embodied in the Digital Signature Standard, utilizes randomness in the signing process. Furthermore, unlike the El Gamal signature scheme, the Digital Signature Algorithm apparently does not transmit enough information in its signatures to allow recovery of the public key. For these reasons the functionality of the Digital Signature Algorithm may be efficiently extended beyond a straight forward digital signature mechanism in order to provide (1) sender anonymity, (2) transaction security, and (3) database security. Thus with respect to (1) it is possible to eliminate the need for an encryption function for the purpose of hiding identities and preventing the linking of transactions to the same individual.
  • the present invention which extends the operation of the Digital Signature Algorithm provides the ability to apply cryptography in order to secure applications such as electronic commerce without relying on the prior art found in several patents on public-key cryptography. Furthermore, it is possible to simultaneously allow the legitimate recipients to access the database entries corresponding to the identity of sender.
  • the Digital Signature Standard signature is also transmitted and Z u,i+1 is computed as an extension of the process of verifying the signature of the Digital Signature Standard.
  • the initial value of z u ,i is randomly or pseudorandonmly generated.
  • the value signP u is stored under the address z u ,i in the central database and is not made public.
  • SHA is the secure hash algorithm function specified in the Secure Hash Standard, as understood by those skilled in the art.
  • z u ,i SHA(y u su (-1) rumodq modp) , where [r u , s u ) constitutes the Digital Signature Standard signature transmitted as part of the previous transaction transmittal, if any. Otherwise, the initial value of z u ,i is used.
  • the signals m, z u ,i , and the current Digital Signature Standard signature as previously described are transmitted.
  • the received z u ,i is used to access sign s u in the database and to verify the current signature of the Digital Signature Standard as applied to the message m and z u ,i . If the signature is valid, the new value of the user password, z-u, i+1 , is computed as SHA(y u s u(- l)rumod(q) mod(p) ) , where SHA(y u (su-1) rumod (q) mod (p) was used during the current signature verification. The new value z u , i +1 overwrites the previous value z u , i .
  • the bank B For each payee S, the bank B sets a limit on the number of outstanding coins for the payee S, i.e., those S-designated coins which are not yet expired and are still in circulation. When the system of the present invention is online, this does not matter because customers wishing to make payments to the payee S can bring coins into and out of circulation in the same transaction. It will be understood that x ⁇ u S indicates that element x is chosen uniformly at random from the set S. Additionally, let the user U be an arbitrary system user, let B be the bank, let the payee S be a seller of goods, and let C be the customer. In the initial set-up the user U acquires the software and provides its identification to the bank B.
  • the bank B provides account_number u to the user U which then provides the bank B with the random seed r 0 U ' B from the software of the user U that will be used for correspondence between the user U and the bank B.
  • the bank B enters ( U, account_number u ,r 0 U ' B ) into the bank database.
  • the customer C uses a one-time identification to identify itself to the bank B and requests g coins from the bank B which are spendable to the seller S .
  • the bank B responds with an encrypted and authenticated message of acknowledgment.
  • the bank B sends ⁇ g (coin i s) ⁇ i ⁇ 1, ...,q ⁇ r 0 C ' S , as well as acknowledgment of the last deposit to the seller S. All transmissions are sent authenticated.
  • the signal r 0 C ' S is transmitted encrypted as well.
  • the customer C sends to the seller r and address c which are authenticated using r 0 C ' S .
  • the value address c can also be encrypted for privacy using ro C,S .
  • the payee S identifies itself to the bank B and sends T to the bank B.
  • H 2 be a one-way hash function mapping into k bits.
  • X is the party that sends encrypted messages, identifiers and authenticated messages.
  • the encryption, identification, and authentication can be sent by either X or Y, in any combination.
  • H 2 ([ri x,y] ⁇ (k/3)+1,...,2k/3 ⁇ ,m i ,0) to Y.
  • Y verifies the authentication message and sends the authentication H 2 ( [ri x ' y] ⁇ k/3+1,...,2k/3 ⁇ ,m i ,1) to X.
  • X verifies Y's authentication message.

Landscapes

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

Abstract

An off-line electronic cash system having an electronic coin, a bank B, a payee S, and a user U with an account at the bank B as well as a user password zu,i, has a method for performing an electronic cash transfer. An electronic coin is withdrawn from the bank B by the user U and an electronic record of the electronic coin is stored by the bank B. The coin is paid to the payee S by the user U. The payee S deposits the coin with the bank B. A determination is made that the coin is spent and the record of the coin is deleted by the bank B. A further deposit of the same coin after the record is deleted is determined. Additionally, a determination is made which user U originally withdrew the coin after deleting the record. To perform these operations, a key pair is generated by the user, including public and secret signature keys. The public signature key along with a user password zu,i and a withdrawal amount are sent to the bank B by the user U. In response, the bank B sends a coin to the user U signed by the secret key of the bank indicating the value of the coin and the public key of the user U. The payee S transmits a challenge counter to the user U prior to receiving the coin.

Description

OFF-LINE COMPATIBLE
ELECTRONIC CASH METHOD AND SYSTEM
Field of the Invention
This invention relates to the field of electronic transactions and, in particular, to the field of electronic transactions related to electronic cash.
Background of the Invention
Electronic cash is a subject of great economic, political and research importance. With advances in computer networks, processor speed and databases, electronic cash systems and methods are likely to become widespread within five to ten years. Other factors likely to lead to more widespread use of electronic cash systems and methods are advances in note counterfeiting technology and the desire of both individuals and businesses for remote and more convenient financial transactions. Electronic cash systems and methods meeting these needs must make a trade-off between privacy and a number of other considerations.
Systems and methods which provide unconditional privacy and anonymity to a payer within an electronic financial transaction are known in the prior art. However, governmental and financial institutions are unwilling to back a completely anonymous system. The reasons for opposing unconditional anonymity, and therefore untraceability, include limiting the amount of user fraud, the desire to restrict new kinds of crime that unrestricted remotely withdrawable and spendable electronic cash would facilitate, and the desire to minimize system complexity and maximize system efficiency. Thus some electronic systems and methods offer little privacy for users. These systems either neglect the privacy issue altogether or trust the banks, the government, or other central authority not to pry into the financial dealings of the users.
Other systems provide much more protection and privacy. However, these systems tend to be more difficult to design because they must prevent the bank from learning too much about the users while still giving the bank the power to prevent or detect fraud by the users. One such system is a blind signature system taught in D. Chaum, "Blind Signatures For Untraceable Payments," Advances in Cryptology- Proceedings of CRYPTO 82, (1983), pp. 199-203. A blind signature scheme such as the one taught by Chaum in the above-referenced article is a protocol in which the signer signs a piece of information for a user without being aware of the message for which it is providing a signature. The signer may be a bank or a minting facility. The recipient of the signature in this scheme does not learn anything from the protocol which would enable this user to sign other information. This type of signature scheme, when used in the context of electronic cash, enables the user of these systems to withdraw money from the bank and spend it with a payee. Furthermore, the payer in these systems may be confident that when the payee deposits the money at the bank, the bank is not able to recognize the money as the same cash withdrawn by the payer.
Other systems which teach blind signature schemes of this nature are disclosed in D. Chaum, A. Fiat and M. Naor, "Untraceable Electronic Cash," Advances in Cryptology-Proceedings of CRYPTO 88, (1990), pp. 319-327, as well as in T. Okamoto and K. Ohta, "Universal Electronic Cash," Advances in Cryptology Proceedings of CRYPTO 91, (1992), pp. 324- 337, Stephan Brands, "Electronic Cash Systems Based on the Representation Problem in Groups of Prime Order," Preproceedings of CRYPTO, (1993), and M. Franklin and M. Yung, "Towards Provably Secure Efficient Electronic Cash," Columbia University, Department of Computer Science, T.R. CUCS-018-92, April 24, 1992. Other blind signature schemes may be found in D. Chaum and T.P. Pedersen, "Wallet Databases With Observers," Advances In Cryptology-Proceedings of CRYPTO 92, (1993), pp. 89-105. Another blind signature scheme of this nature may be found in D. Chaum, "Security Without Identification: Transactions To Make Big Brother Obsolete," Comm. ACM 28, (October 1985), p.10. Further blind signature protocol of this type known in the prior art is taught in D. Chaum, Privacy Protected Payments: Unconditional Payer and/or Payee
Untraceability, (North Holland, SmartCard 2000, 1988) .
It is also known to provide an electronic cash protocol based upon the difficulty of computing cube roots, or more generally Jcth roots, modulo an RSA modulus with unknown factorization. In this type of protocol a bank knows the factorization of a modulus N and is able to compute y1 /k mod N given arbitrary y, where k is relatively prime to Φ (N). Given a collision-free one-way hash function H, the user chooses random x, r mod N and sends rkH{x) mod N to the bank. The bank then sends r H(x)1/k mod N to the user who extracts the electronic coin (x, H(x)1/k mod N), using its knowledge of x and r. The extracted electronic coin is therefore unknown to the bank, in the sense that it cannot be associated with rkH(x) mod N.
Techniques proposed in the prior art for dealing with the problem of anonymously providing change in electronic cash systems may be found in T. Okamoto and K. Ohta, "Universal Electronic Cash," Advances in Cryptology-Proceedings of CRYPTO 91, (1992), pp. 324-337 as well as in T. Eng and T. Okamoto, "Single Term Divisible Electronic Coins," Preproceedings of Eurocrypt 94, (1994), pp. 311-323. Electronic cash systems of this type prevent the bank from determining which user withdrew an electronic coin. However, in these systems the banks are able to recognize different pieces of a coin as belonging to the same coin. Thus the pieces of the coin are linkable by the bank.
It is therefore desirable to provide an electronic cash system and method that adequately protects the identity of a user, i.e., payer, from a payee in an electronic financial transaction. Furthermore, it would be desirable to be able to require that the banks that issue and accept the deposit of the electronic coins can cooperate with each other in order to trace the electronic coins, in the case that the two banks are distinct. Regarding trustee traceability, there should be a trustee system in which a coin minter and the bank of the user of the electronic coins are among the trustees. Such a system should provide payer anonymity with minimal system complexity, storage space, bandwidth and processing demands.
In off-line electronic cash transaction systems it is often desirable to allow the user of an electronic coin to designate an individual identified payee to enable payment of the coin directed only to the designated payee. This feature allows a user to to make an off-line purchase in such way that the recipient is assured that the electronic cash is not already overspent. Furthermore, the recipient of the coin can determine that the electronic cash is not already overspent without conferring with the bank which issued it to the user. Thus, payment involving electronic cash meeting these criteria is only valid with the designated recipient in systems of this nature.
Additionally, when electronic coins are deposited by a payee with the issuing bank, the bank would like to be able to determine that the coin is not overspent or counterfeit. In order to do this it is known for the bank to maintain exhaustive lists of the coins which it has issued. Upon receiving a deposit of an electronic coin the bank may compare the received deposit with the list of issued coins. If the received coin is on the list and is not overspent, the bank may make payment on it.
When it is determined that a com is fully spent the bank which issued the coin would like to delete it from the list in order to avoid accumulating large numbers of records of spent coins. Such accumulated records require valuable memory space in the database maintained by the bank. However, when such coins are deleted from the database the bank is unable to determine to whom the coins were issued if they are later redeposited as part of an overspending or fraud attempt, or at least unable to prove fraud. The bank must therefore establish a trade-off between its ability to take anti-fraud measures and the memory space required to store used electronic coins. Thus, it would be useful to be able to determine information such as the identity of the user to whom a fraudulently spent coin was originally issued. Furthermore, it is preferred that this information can be determined without requiring excessive computer memory space.
One known cash system, as provided in the prior art by Rosen, is non-anonymous and transactions are linkable. This system is taught in European Patent Application No. 0 542 298 A2 entitled Electronic Monetary System. Another known system in the prior art is NetCash provided by Medvinsky and Neuman, Proceedings of the First ACM Conference on Computer and Communications Security, (November 1993). Multiple trustees, or servers, are required for tracing transactions in the system taught by Medvinsky and Neuman in order to provide a measure of anonymity for users. The "trusted" server is chosen by the exchanging user.
In the system of Medvinsky and Neuman, as money is exchanged through multiple cash servers the number of trustees is increased because all of the servers must collaborate in order to follow the path of the money. In this system, each of the trustees must have the power to mint money. As long as a user only presents an electronic coin to a currency server, the server should not be aware of the identity of the user. The designers of this system do not intend that these servers legally collaborate in order to trace user identities. Furthermore, honest servers are expected not to retain records that link or pair accepted and issued coins. If these constraints are followed it should not be possible to trace the coins. However, it is undesirable to require a number of trustees with the power to mint since it is better to have fewer minters.
The Medvinsky-Neuman system provides a payee-coin to prevent over-spending by a user. The payee-coin is only accepted by a designated payee since only the designated payee can prove to the server that it holds a valid coin. The user cannot convert the payee-coin to another coin and later accept a receipt for unpaid merchandise. The payee- coin may incorporate a one-time public key chosen by the payee. However, the resulting receipt is meaningless in this system because it is not associated with the actual payee in an adjudicatable manner.
A payor-coin is also provided in the system of Medvinsky and Neuman. The payor-coin prevents someone other than the payor from spending the coin or receiving a receipt for merchandise. Even the cash server cannot spend the payor-coin. The public key used with the payor-coin can be chosen for an individual coin by the payor when the payor purchases the coin. This protects the identity of the payor from the payee when later presenting the receipt . It also protects the identity of the payor from the server when purchasing a coin with another anonymous coin.
The system taught by Medvinsky and Neuman is heavily reliant upon encryption. It uses encryption in all protocols. This is undesirable because encryption requires extra memory space and processing time. Another known prior art system, proposed by Chaum, partially solves this problem. This Chaum system provides a user with protection against framing and tracing using information-theoretic and complexity techniques.
However, this Chaum system has problems with fungibility, where fungibility is understood to be the ability to make change. In the most basic system proposed by Chaum each electronic coin has a value of a predetermined denomination wherein the denomination is determined by the minting key of the issuing bank. Much like present-day physical coins these electronic coins cannot be broken into smaller pieces. Instead, the user must have correct change or the payee must provide correct change. The system of Chaum provides techniques to allow the user to break the coin down into smaller pieces. However, these techniques greatly increase the computation time required by the software of the user. The reasons for this complexity are the aspects of this Chaum system that keep the spending of the user private even from the bank. This is very inconvenient and it is therefore desirable to have an electronic cash system wherein electronic coins may be easily broken down into smaller pieces of arbitrary value with a small amount of overhead computation, thereby providing no difficulty with respect to fungibility. This Chaum system also has rather complex coding requirements. A large amount of computation is required by the user. For example, in order to withdraw one non-fungible coin a user must perform at least ten modular exponentiations involving a base and exponent that are numbers of about 800 bits each. Additionally, the application of a one-way hash function is also required in this system. A withdrawal of $100 that is fungible would require at least one hundred applications of one-way hash functions. It is desirable that code speeds which are significantly higher than this be available if the system is to be convenient to use.
Additionally, electronic coins within the system proposed by Chaum require a significant amount of space. For example, in a system based upon the representation of elements of a group of prime order, a single coin may be represented by at least seven numbers of about 800 bits each. Thus a single coin may require at least 5600 bits. Due to the lack of fungibility, several coins of this size may be required to meet the needs of the user which may be met by a single more fungible coin. The space required by the coins is important to both the user and the banks. High storage requirements for the user may limit the ability of the user to benefit from the system. High storage requirements for the bank may mean, among other things, that searches to determine overspending of electronic coins are slower. The same factors leading to large space requirements cause a taxing of the communication bandwidth available to users of the system.
In the system disclosed by Chaum, the banks are unable to differentiate between electronic coins that are legitimately withdrawn from the bank and coins created by criminals using the minting key. As long as the value of forged coins remains low relative to the amount of legitimate money in circulation, the banks are unable to determine that there is a problem. Even if the value of the forged coins that are deposited becomes high, the bank may only be aware that some unknown party has created forged coins . It may still be unable to distinguish between them and legitimate coins.
Therefore, if the minting key is compromised there is potential for discrediting the system and for serious financial losses on the part of the banks. The reason for the difficulty in detecting the forged coins is that the banks do not know which coins have been legitimately withdrawn. This is an unavoidable consequence of unconditional anonymity. Thus, it is desirable to provide a system wherein banks are able to identify and reject money that is created with a stolen minting key immediately upon an attempt to deposit the money, while still permitting a significant amount of user anonymity and not imposing excessive memory requirements.
Other problems exist in known electronic cash systems and methods. For example, in an electronic cash system and method which is software- based on the user end, the potential exists for the creation and widespread dissemination of defeating software. The defeating software may reconfigure or replace the authorized software in order to enable cheating. A particular goal of such spoofing may be to enable overspending of electronic cash. Banks must be cognizant of the possibility that such reverse- engineering of software could enable an individual to produce a large number of electronic coins which are not backed by funds actually on deposit with the bank. These fraudulent electronic coins could also be distributed across networks as a malicious hacking exercise in addition to an attempt to steal money from the system.
Summary of the Invention
An off-line electronic cash system having an electronic coin, a bank B , a payee S, and a user U with an account at the bank B as well as a user password Zu,i, is provided with method for performing an electronic cash transfer. In the electronic cash transfer an electronic coin is withdrawn from the bank B by the user U and an electronic record of the electronic coin is stored by the bank B. The electronic coin is paid to the payee S by the user U and the payee S deposits the electronic coin with the bank B. A determination is made that the electronic coin is spent in accordance with the deposit and the record of the electronic coin is deleted by the bank B in response thereto. A further deposit of the same electronic coin after the electronic record is deleted is determined. Additionally, a determination may be made which user U originally withdrew the electronic coin after the record is deleted.
Brief Description of the Drawings
The foregoing summary, as well as the following detailed description of preferred embodiments of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments which are presently preferred. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings: Fig. 1 is a flow chart representation of a setup protocol suitable for use in the electronic cash system and method of the present invention; Fig. 2 is a flow chart representation of an electronic cash withdrawal protocol suitable for use in the electronic cash system and method of the present invention;
Fig. 3 is a flow chart representation of an electronic payment protocol suitable for use in the electronic cash system and method of the present invention;
Fig. 4 is a flow chart representation of an electronic deposit protocol suitable for use in the electronic cash system and method of the present invention;
Fig. 5 is a flow chart representation of an electronic withdrawal protocol adapted for use with a designated payee within the electronic cash system and method of the present invention;
Fig. 6 is a flow chart representation of an electronic payment protocol adapted for use only with a designated payee within the electronic cash system and method of the present invention; Fig. 7 is a flow chart representation of an electronic withdrawal protocol adapted to permit tracing of a user by encoding information within the electronic coin within the electronic cash system and method of the present invention; Fig. 8 is a flow chart representation of an electronic payment protocol adapted to permit a payee to identify a minting bank suitable for use with a plurality of banks within the electronic cash system and method of the present invention; Fig. 9 is a flow chart representation of an electronic deposit protocol adapted for use with the electronic payment protocol of Fig. 8 within the electronic cash system and method of the present invention; Fig. 10 is a flow chart representation of an electronic setup protocol suitable for use with a trustee system within the electronic cash system and method of the present invention;
Fig. 11 is a flow chart representation of an electronic withdrawal protocol adapted for use with the protocol of Fig. 10 within the electronic cash system and method of the present invention;
Fig. 12 is a flow chart representation of an electronic withdrawal protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention; Fig. 13 is a flow chart representation of an electronic payment protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention;
Fig. 14 is a flow chart representation of an electronic deposit protocol adapted for the anonymous transfer of an electronic coin using encryption and suitable for use within the electronic cash system and method of the present invention;
Fig. 15 is a flow chart representation of an electronic transfer protocol for transferring electronic cash from a payee to a third party suitable for use within the electronic cash system and method of the present invention; and
Fig. 16 is a flow chart representation of an electronic deposit protocol suitable for use by a third party and suitable for use within the electronic cash system and method of the present invention.
Detailed Description of the Preferred Embodiment
Referring now to the drawings, wherein like numerals are used to indicate like elements throughout the several figures, there is shown in Fig. 1 the electronic cash setup protocol 100 for use in a presently preferred embodiment of an electronic cash system in accordance with the present invention. It should be appreciated by those skilled in the art that while a financial-based transaction system is shown and described herein the present invention is not limited to financial-based transaction systems. It will be understood that the present invention encompasses other non-financial transaction systems including, but not limited to, identification or access control systems and voting systems. It will also be understood that all values which are digitally signed in the present invention are preprocessed in the system and method of the present invention using appropriate redundancy and/or one-way hash functions in a manner understood by those skilled in the art. Although both the messages and their digital signatures are transmitted in the instant description, it will be understood that in some cases this may be unnecessary. For example, it is not necessary to transmit both a message and its digital signature when the message is recoverable from its digital signature.
In the electronic cash setup protocol 100 the user U is any user entity which later withdraws and spends electronic cash and the bank B is any bank or other entity from which the user U withdraws the electronic cash. The seller S or payee S is any seller or payee entity which receives the electronic cash from the user 17 and deposits the received electronic cash at a bank entity such as the bank B in later protocols described hereinbelow. It is assumed in the electronic cash setup protocol 100 that the user U and the bank B have a line of secure private communication for the proper functioning of the later withdrawal procedure described hereinbelow. This feature is important in order to minimize the use of encryption within the system of the present invention and thereby avoid the computation requirements associated with encryption. As described in detail hereinbelow the secrecy of the public signature key of the user U is relied upon to keep transactions of the user U anonymous in the present invention.
In the electronic cash setup protocol 100 the user U of the electronic cash system of the present invention obtains the required software and provides a user identification to the bank B as shown in block 104. In response to the transmission of block 104 the bank B provides a system identification, account_numberu, to the user U as shown in block 108. The system identification account _number u of block 108 may later be used in the anti-fraud operations of the electronic cash system if the user U attempts to overspend the electronic cash withdrawn from the bank B. In the preferred embodiment of the invention the system identification value, account_numberu, transmitted in block 108 may also serve as the bank account number of the user U. Thus, if the user U sets up other bank accounts, for example at different banks, then the user U may acquire other identifications of this type. In block 108 of the electronic cash setup protocol 100 the bank B also provides the user U with the bank public signature key signPB. it will be understood however that in an alternate embodiment the public signature key signPB may also be provided to the user U by the software the user U acquires. The value of signPB transmitted by the bank B in block 108 may be used later to verify that the information had been signed by the bank B. Additionally, the user U may use the public signature key signPB to identify the bank B and to verify messages transmitted by the bank B .
In block 112 the public signature key signPB is verified by the user U by comparing it with the public signature key signP'B. The public signature key signP'B is received by the user U in the software of block 104. If the public signature key signP'B of the bank B is verified in this manner, the user U sends its own public signature key, signPu. The public signature key signPB of the user U corresponds to the secret key, signs u, of the user U which is also received by the user U in the software of block 104 or is generated using such software. This transmission of its public signature key signup by the user U is shown in block 116 of the setup protocol 100. In block 120 the bank B stores the identification of the user U, account_numberu, and signPu into its database.
Referring now to Fig. 2, there is shown a flow chart representation of the electronic cash withdrawal protocol 200 of the present invention. The electronic cash withdrawal protocol 200 is a method for permitting the user U to withdraw electronic cash from the bank B. The preferred embodiment of the electronic cash system and method of the present invention is based upon electronic coins which are represented, at least in part, by digital signature key pairs. In the preferred embodiment the electronic coins are of the form (coin_signP, coin_signs) wherein the key coin_signP is a public coin signing key of the user U. The key coin_signs is a secret coin signing key of the user U corresponding to the public coin signing key coin_signP. Therefore, in the electronic cash withdrawal protocol 200 of the present invention the user U which is withdrawing an electronic coin from the bank B randomly or pseudorandomly generates a digital signature key pair {coin_signP, coin_signs) as shown in block 204. It will be understood by those skilled in the art that any known method of providing digital signature key pairs may be used. For example the Digital Signature Standard, DSS, or RSA may be used to generate the signature key pairs of block 204. In block 208 of the electronic cash withdrawal protocol 200 the user 17 transmits a copy of the public key coin_signP, its user password zu, i, and withdrawal_value to the bank B. It will be understood that withdrawal_value is the amount of electronic cash that the user U wishes to withdraw from the bank B. The values transmitted by the user U in block 208 are signed by the user U with the long-term user secret key signs u. In order to ensure that no one else can spend the electronic coin being withdrawn the user 17 never reveals the secret key coin_signs.
In one embodiment of the present invention the bank B maintains lists of all electronic coins withdrawn and all electronic coins deposited. The bank B can therefore check that no legitimate electronic coin is being spent beyond the maximum value, withdrawal_value, transmitted in block 208. Using these lists the bank B can also determine that no counterfeit coins are being introduced into the system in case the signature key of the bank B is compromised. However, embodiments of the present invention maintaining lists of this type require a large amount of computer memory storage in order to maintain records of all such electronic coins.
In block 212 the bank B identifies the user U by looking up the user password zu ,i in its database. In block 216 the bank B verifies the user transmissions of block 208. In the preferred embodiment of the invention the user password zu ,i is an indexed password. Therefore, as shown in block 220, the bank B independently computes the next value of the user password, zu,i+1 , and deducts the amount of the withdrawal from the bank account of the user U. The bank B signs the public key coin_signP as well as the coin value withdrawal_value as shown in block 224 using its secret key signs B. This permits the payee S to recognize the electronic coin as valid currency with a maximum value withdrawal_value when it receives the coin from the user 17. In block 228 the user U verifies the transmission of block 224 using signPB. The user 17 then updates the user password zu ,i to obtain the next password zu,i+l as shown in block 232 independently of the bank B.
It will be understood by those skilled in the art that in the electronic cash withdrawal protocol 200 all messages may be sent in the clear and the user U may thus identify itself to the bank B without using traditional encryption methods. Therefore much less computation is required for the user U to send the password zu ,i in the first round as shown in block 208. Additionally much less computation is required for the bank B to look up the user password zu,i in i ts database as shown in block 212 in order to determine to whom the password zu ,i corresponds. Because there is randomization in the signature scheme performed by the user U the signing of messages by the user U does not reveal its identity.
Referring now to Fig. 3, there is shown the electronic cash payment protocol 300 of the present invention. Prior to payment of the electronic cash amount payment_value to a payee S by the user 17 the payee S sends a value, counter, as a challenge to the user U. The payee challenge is shown in block 304 of the payment protocol 300. In block 304 counter is also updated by the payee S after transmission to the user U in order to provide a unique value for each challenge. The purpose of the challenge by the payee S is to prevent replay attacks wherein a user U can resend a transaction to a payee S or wherein a payee S can resend a transaction to a bank B. Another attack prevented by the payee challenge of block 304 could come from an eavesdropper who could try to replay the same conversation with the payee S to illegally acquire goods from the payee S . The eavesdropper in this case may operate without the knowledge of the user U. In block 312 of the electronic cash payment protocol 300 the user U uses its secret value of coin_signs to compute coin_signs {payment_value, S, counter), wherein S in this context is understood to be an identification of the payee S . In block 316 the user U sends the values of wi thdrawal_value and coin_signP as well as a partial representation of the electronic coin signs B ( coin_signP, wi thdrawal_value) signed by the bank B to the payee S . The user U also sends the signed electronic coin payment computed in block 312, coin_signs {payment_value, S, counte ), which is computed over the transaction amount, the identification of the payee S , and the challenge received from the payee S . In block 320 the payee S verifies the signature of the bank B on the public part of the electronic coin and in block 324 the payee S verifies the signature of the payment of the coin.
Referring now to Fig. 4, there is shown the electronic cash deposit protocol 400 of the present invention. In block 404 of the electronic cash deposit protocol 400 the payee S which received an electronic payment from the user U sends a transcript of the transaction as set forth in the payment protocol 300 to the bank B. The bank B verifies that the value of the challenge counter, represented as counter, used by the payee S is correct by comparing it with its own copy, countersB , as shown in block 408. In block 412 of the deposit protocol 400 the bank B verifies part of the transmission of block 316 by determining that the payment of the amount payment_value was made to the payee S with the challenge counter using the coin corresponding to the secret coin signing key coin_signs . In block 416 the bank B determines that ( coin_signP, wi thdrawal_value) was used in a legitimate withdrawal such as a withdrawal as set forth in the electronic cash withdrawal protocol 200 hereinabove. The bank B also verifies that the sum of the deposits using ( co in_s ignP, wi thdrawal _value) does not exceed the value withdrawn as shown in block 420. At some point the appropriate account of the depositor is adjusted to reflect the deposit made using the deposit protocol 400. Referring now to Fig. 5, there is shown the designated payee withdrawal protocol 500 of the method and system of the present invention. The designated payee withdrawal protocol 500 may be used when a user U wants to make a purchase in such a way that the payee S can be assured without conferring with the bank B that the electronic cash used in the purchase is not overspent. The designated payee withdrawal protocol 500 requires the identity of the payee S to be encoded or embedded in an electronic coin withdrawn from the bank B and signed by the bank B. Payments involving electronic cash obtained using the withdrawal protocol 500 are then only valid with the designated payee S . Therefore the electronic coin may be referred to as a directed electronic coin. The setup protocol required prior to the operation of the designated payee withdrawal protocol 500 may be the same as the electronic cash setup protocol 100 used in connection with the withdrawal protocol 200 wherein the electronic cash withdrawn could be used with any payee S.
In the designated payee withdrawal protocol 500 the user U withdrawing an electronic coin from the bank B randomly generates a digital signature key pair ( coin_signP, coin_signs) as shown in block 504. It will be understood by those skilled in the art that any known method of providing digital signature key pairs may be used in block 504 to generate a digital signature key pair as previously described with respect to block 204. In the prefe rr ed embodiment DSA may be used.
In block 508 the user 17 transmits the user password zu ,i , a copy of the public key coin_ signP, wi thdrawal_value and the value S which is a representation of the payee S . The value wi thdrawal _value is the amount of electronic cash the user U wishes to withdraw from the bank B. It will be understood that it is the inclusion of the identification of the payee S within the electronic coin in the manner set forth in block 508 that creates the ability to provide a designated payee electronic coin. The values transmitted by the user 17 in block 508, including the representation of the designated payee S , are signed by the user U using the user secret key, signs u . In order to ensure that no one else can spend the electronic coin being withdrawn the user U never reveals the secret key coin_signs .
In block 512 the bank B identifies the user U by looking up the user password zu ,i in its database. In block 516 the bank B verifies the user transmissions of block 508. In the preferred embodiment of the invention the user password zu ,i is an indexed password. Therefore, as shown in block 520, the bank B independently computes the next value of the user password, zu,i+1. The bank B then deducts the amount of the withdrawal from the bank account of the user U. The bank B signs the public key coin_signP as well as the value of the electronic coin wi thdrawal_value and the representation of the designated payee S as shown in block 524. The signing of these values by the bank B is performed using its secret key signsB so that the payee S can recognize the electronic coin as valid currency when it receives the electronic coin from the user 17. In block 528 the user U verifies the transmission of block 224 using signPB . The user U then updates the user password zu ,j to obtain the next user password zu ,i+1 as shown in block 232. The update performed by the user U in block 232 is independent of the bank B. It will be understood by those skilled in the art that in the electronic cash withdrawal protocol 500 all messages may be sent in the clear and that the user U may thus identify itself to the bank B without using encryption. Therefore much less computation time is required for the user U to send the user password zu ,i in the first round as shown in block 508. Additionally, much less computation time is required for the bank B to look up the user password zu ,i in its database in order to determine the party to which the password zu ,i corresponds as shown in block 512. Because there is randomization in the signature scheme of the user U the signing of messages by the user U does not reveal its identity within the designated payee withdrawal protocol 500 of the present invention.
Referring now to Fig. 6, there is shown the designated payee payment protocol 600 of the present invention. Using the designated payee payment protocol 600 a payee S can be certain that the user 17 has not used an electronic coin received from the user U to pay anyone else. The designated payee payment protocol 600 may be used in cooperation with the designated payee withdrawal protocol 500. The deposit protocol required in connection with the designated payee payment protocol 600 may be similar to the basic electronic cash deposit protocol 400 described hereinabove except that in the designated payment protocol 600 the bank B verifies that the payee S of the directed payment is the same as the payee S which is encoded or embedded within the electronic coin. Prior to payment of the electronic cash amount payment_value to a payee S by a user 17 the payee S sends a value, counter, to the user U as a payee challenge. The payee challenge is shown in block 604 of the designated payee payment protocol 600 wherein the challenge counter is updated by the payee S after transmission to the user 17. The purpose of the payee challenge is to prevent replay attacks wherein a user U can resend a transaction to a payee S . Another type of replay attack prevented by the payee challenge is one in which a payee S can resend a transaction to a bank B. A further attack prevented by the payee challenge of block 604 could come from an eavesdropper who could try to replay the same conversation with the payee S to illegally acquire goods from the payee S . Such an eavesdropper may operate without the knowledge of the user U. In block 612 of the electronic cash payment protocol 600 the user U uses its secret value of coin_signs to compute part of the transmission, coin_signs { payment _value, S , counter) . In this context S is an identification of the designated seller S or payee S as previously described with respect to the designated payee withdrawal protocol 500. In block 616 the user U sends the signed value of block 612 as well as a partial representation of the electronic coin signs B ( coin_signP, wi thdrawal_value, S') signed by the bank B to the payee S . The user U also sends the signature of the coin, coin_signs {payment_value, S , counter) which includes the transaction amount, the identification of the payee S and the challenge received from the payee S . In block 620 the payee S verifies the signature of the bank B on the public part of the electronic coin and in block 624 the payee S verifies the signature of the electronic coin received from the user U during the purchase. The bank verifies that the payee S has not received more than wi thdrawal_value, for the coin in block 628. Referring now to Fig. 7, there is shown the electronic cash withdrawal protocol 700. The electronic cash withdrawal protocol 700 is adapted to minimize the record keeping required by a bank B while permitting the bank B to control overspending and fraud. This and other objectives are realized by permitting the bank B to encode or embed predetermined information about a user U within an electronic coin withdrawn using the withdrawal protocol 700. By encoding information within an electronic coin as set forth in the withdrawal protocol 700 the bank B and no one else can trace the user C7 which withdraws the electronic coins.
Furthermore, using this method the bank B can perform the tracing of electronic coins without retaining records of spent coins indefinitely. Thus, when the full value of a legitimate electronic coin minted using the electronic cash withdrawal protocol 700 has been spent it may be deleted from the bank database and the bank B must maintain only a list of the currently circulating legitimate electronic coins. The ability to delete records of spent electronic coins greatly reduces the storage requirements for the bank B.
If a deleted coin is subsequently overspent the bank B can determine the identity of the user 17 to whom the electronic coin was issued by exhaustively searching over all user account numbers to find a user account account_numberu such that β=H {bank_id_key, coin_signP, account_numberu). Parties other than the bank B cannot perform the search for the user account because they do not know the value bank_id_key. The complicity of the identified user U may be verified through its signature signs u{coin_signP, withdrawal_value,&). If the bank B encounters an electronic coin which is not in the database of currently circulating legitimate coins a determination is made whether there is no user U such that both β=H (bank_id_key, coin_signP, account_numberu) and the user signature on { coin_signP, wi thdrawal _value, β ) are valid. If these conditions are met then the electronic coin is
determined to be counterfeit.
The existence of a counterfeit electronic coin located in this manner may indicate that the minting key of the bank B has been compromised. If a minting key has been compromised it can then be changed. All counterfeit electronic coins minted using the compromised key can be eliminated by Setup, requiring that all electronic coins using the compromised minting key be exchanged directly with the bank B. Setup, payment and deposit protocols suitable for use with the electronic cash withdrawal protocol 700 may be substantially the same as those described hereinabove. Therefore, in the withdrawal protocol 700 the user U withdrawing an electronic coin from the bank B randomly generates a digital signature key pair i coin_signP, coin_signs) as shown in block 704. It will be understood by those skilled in the art that any known method of providing digital signature pairs may be used for providing the key pair of block 704. In block 708 the user 17 transmits a copy of the public key coin_signP, its user password Zu , i , and withdrawal_value . It will be understood that wi thdrawal value is the amount of electronic cash the user U wishes to withdraw from the bank B. The values transmitted by the user U in block 708 are signed by the user U with the user secret key, signs u. In order to ensure that no one else can spend the electronic coin being withdrawn the user U never reveals the secret key coin_signs.
In block 712 the bank B identifies the user U by looking up the user password zu ,i in its database. In block 716 the bank B verifies the user transmissions of block 708. In the preferred embodiment of the invention the user password zu ,i is an indexed password. Therefore, as shown in block 720, the bank B independently computes the next value of the user password, zu,i+1, and then deducts the amount of the withdrawal from the bank account of the user U. The bank B signs the public key coin_signP as well as the electronic coin value withdrawal_value as shown in block 724 using its secret key signs B. In this manner the payee S can recognize the electronic coin as valid currency when it receives the coin from the user U. In block 728 the user U sends its signed values to the bank B. The bank verifies the transmission of block 728 in block 732. In block 736 the bank B, appends the values transmitted in block 708 using its secret key signPB, signs the public key coin_signP of the user U, the withdrawal value, the hash operation of block 724 and the signed transmission transmitted from the user U in block 726. The signed value set forth in block 736 is transmitted to the user U in block 740. The user U verifies this transmission in block 744 and updates the user password zu ,i to obtain zu, i +1 as shown in block 748 independently of the bank B.
It will be understood by those skilled in the art that when using the electronic cash withdrawal protocol 700 all messages may be sent in the clear. Furthermore, it will be understood that the user U may thus identify itself to the bank B without using traditional encryption. Therefore much less computation time is required for the user U to send the user password zu ,i in the first round as shown in block 708. Additionally much less computation time is required for the bank B to look up the user password zu,i in its database in order to determine to whom the user password zu ,i corresponds as shown in block 712. Because there is randomization in the signature scheme of the user U, the signing of its messages by the user 17 does not reveal its identity.
Referring now to Figs. 8, 9, there are shown the multibank electronic cash payment protocol 800 and the multibank electronic cash deposit protocol 900. The two multibank electronic cash protocols 800, 900 may be used in the electronic cash system and method of the present invention when a plurality of banks are involved in an electronic cash transaction. In the multibank electronic cash protocols 800, 900 the user 17 is any user entity which withdraws and spends electronic cash, as described previously, and the payee a is any seller or payee entity which receives and deposits the electronic cash received from the user U. The bank Bu is a bank wherein the user U has a bank account and the bank Bs is a bank wherein the payee S has a bank account.
During the setup prior to a transaction involving more than one bank in the electronic cash system of the present invention, the user U may perform a basic setup protocol as set forth in the electronic cash setup protocol 100 described hereinabove. Additionally, the withdrawal protocol performed by the user U under these circumstances may be substantially the same as that set forth in the electronic cash withdrawal protocol 200 described hereinabove. One exception is that the minting key, signs Bu, of the bank Bu in the multibank protocols 800, 900 may be different from the minting keys of other banks. Furthermore, the multibank payment protocol 800 may be substantially similar to the electronic cash payment protocol 300 described hereinabove except that in the multibank case the user U identifies the bank Bu that minted the electronic coin so that the payee S may use the correct bank public key to verify the validity of the electronic coin it receives.
In order to execute the multibank protocols 800, 900 the payee S selects a random value γs and sends it, along with the challenge counter, counter, to the user 17 as shown in block 804. The user U then increments the counter. The user U incorporates the identity of the payee S directly into the payment record of the electronic coin as shown in block 808 by computing the value ρs = H(ys , counter, S) wherein S is a representation of the seller S . Due to the step set forth in block 808 it is possible to link the payment of the payment protocol 800 to the payee S only by eavesdropping on the payment or by knowing the random value γs. In particular, this protects the anonymity of the payee S from the issuing bank Bu of the user U if the bank Bu is different from the bank Bs where the payee S deposits the coin. The user U then signs the payment value and the value computed in block 808 using the key coin_signs as shown in block 812.
The payee S may already know the public signing key of the issuing bank Bu. If not the user U may send that key also. An expiration date may also be provided by the user U. If the user U sends the signing key in this manner it must be certified by an independent authority. As shown in block 816 the user U sends the value computed in block 812 along with a signed signal including its public key, coin-signP, the withdrawal value, wi thdrawal_value, and the identity of the bank Bu. In blocks 820, 824 the payee S verifies the transmissions of block 816 within the multibank electronic cash payment protocol 800.
In the multibank electronic cash deposit protocol 900 the payee S sends the random value γs to its own bank Bs as shown in block 904. The role previously performed by the single bank B is then divided between the bank Bs of the depositor and the bank Bu that issued the electronic coin exchanged by the user U and the payee S These operations are set forth in blocks 908-928.
The value Ps=H(γs, counters Bs, S) is computed by the bank Bs in block 908 and the transmission of block 904 is verified in block 912. The bank Bu then transmits to the bank Bu as shown in block 916. In blocks 920, 924 bank B verifies that the payee S is the intended recipient of the electronic com and that the payee S has not made the same deposit before. The bank Bu also verifies that the electronic coin has not been overspent and that it is not counterfeit. The bank Bu then credits the bank Bs in block 928 for the amount payment_value if all verifications of blocks 920, 924 are performed correctly. The bank Bs then credits the payee S for amount payment_value within the multibank electronic cash deposit protocol 900.
Referring now to Fig. 10, there is shown the trustee-based tracing setup protocol 1000. In the trustee-based tracing setup protocol 1000 only one of the trustees, for example the bank B, needs the power to mint or coin electronic money. The bank A may be a bank without the power to mint electronic coins in the protocol 1000. Furthermore, it will be understood by those skilled in the art that the entities described as bank A and bank B in the instant embodiment need not be banks in alternate embodiments of the present invention.
In block 1004 of the trustee-based tracing bank protocol 1000 the user U acquires the required software as previously described in block 104 of the electronic cash setup protocol 100. The user 17 also sends its identification to the bank A in block 1004. The bank A later anonymously sends to the minting bank B all the information the bank B requires to sign the coin withdrawn by the user U. The bank A may act as a courier that is not able to determine which coins the user U and the bank B are communicating.
To implement this the bank A sends the account number of the user U to the user U in block 1008 and the user U sends its public signature key, signPu, to the bank A in block 1012. The bank A puts the identification of the user U, the account number and public key into its database as shown in block 1016 and sends the bank public signature key, signPB, to the user 17 in block 1020. The user U may generate any number of encryption key pairs and generate any number of electronic coins as shown in blocks 1024, 1028. The withdrawal values, along with the public keys of block 1024 and electronic coins encrypted with the public encryption key of the bank B, are then sent to the bank A as shown in block 1032. At a later time the withdrawal values, the p values, the encryption keys, and the encrypted electronic coins are sent to the bank B as shown in block 1036. The bank B decrypts to recover coin_signP K as shown in block 1040 and sends the coins to the bank A as shown in block 1044 of the trustee-based tracing setup protocol 1000
Referring now to Fig. 11, there is shown the trustee-based withdrawal protocol 1100. In the trustee-based withdrawal protocol 1100 the user U sends a request for a withdrawal and a value K to a courier bank A as shown in block 1104. The courier bank A then deducts the withdrawal value associated with k, wi thdrawal_valueK , from the account which the user 17 has previously opened as shown in block 1108. The courier bank A also sends encryptp uK (signs B ( coin_signP K , wi thdrawal_valuek ,ρKB), signS B
{ coin_signP K , encryptp U (K ) ρkB) ) ) to the user 17 as shown in the block 1112. Thus, in block 1112 of the withdrawal protocol 1100 the bank A sends to the user U an electronic coin that the bank B has previously signed without the bank A being able to read the coin. In block 1116 the user U decodes the encrypted transmission of block 1112. The withdrawal value and signatures are verified by the user 17 in blocks 1120, 1124.
The protocols used for payment and deposit in connection with the trustee-based tracing of the system of the present invention may be similar to the electronic cash payment protocol 300 and the electronic cash deposit protocol 400 as set forth hereinabove. In the case of the trustee-based tracing protocol the courier bank A and the bank B may use a combination of hashing with secret keys and identification of the user U in order to be able to trace the electronic coin back to the user U. They do so in such a way as to be able to prove that the electronic coin being traced was issued to the user U without weakening the anonymity of other coins in the system.
Referring now to Figs. 12, 13, 14, there are shown the anonymous transfer withdrawal protocol 1200, the anonymous transfer payment protocol 1300 and the anonymous deposit protocol 1400. The concept of tokens used in the anonymous transfer protocols 1200, 1300 and 1400 to enable transferability is disclosed in more detail in D. Chaum and T. P. Pedersen, "Transferred Cash Grows in Size," Advances in Cryptology - Proceedings of Eurocrypt 92, (1993), pp. 390-407. In the system of the present invention it is possible to use the anonymous transfer protocols 1200, 1300 and 1400 to obtain anonymous transferability of electronic cash using encryption thereby saving substantial computation time. The setup phase required to use the anonymous transfer protocols 1200, 1300 and 1400 may be the same as that previously described with respect to the electronic cash setup protocol 100 except that the user U in the anonymous transfer protocols 1200, 1300 and 1400 learns the public encryption key, encryptPB, of the bank B. There are two types of withdrawals associated with anonymous transferability in the fer protocols 1200, 1300 and 1400. The first type of withdrawal is withdrawal of an ordinary electronic coin with a cash value withdrawal_value. The method for performing this type of withdrawal is substantially similar to that set forth hereinabove with respect to the electronic cash withdrawal protocol 200.
The other type of anonymous withdrawal is withdrawal of a transfer token, ( token_signP, token_signs), sign_tokens B, ( token_signP), for use in receiving payments and transferring ordinary electronic coins by a party which is paid in one transaction and wishes to use the electronic coins to pay another entity. This is the type of transfer set forth in the anonymous transfer protocols 1200, 1300.
The transfer tokens of the anonymous transfer protocols 1200, 1300 have no inherent cash value. If the transferrer of the electronic coin of anonymous tranfer protocols 1200, 1300 attempts to overspend a transferred electronic coin the bank B can use the public part of the transfer token to identify the culprit.
In the withdrawal of a transfer token using the anonymous withdrawal protocol 1200 the key pair
(token_signP, token_signs) is generated in block 1204.
The user U sends to the bank B the user password,
Zu,i, the public key of the key pair as set forth in block 1204, and a copy of the public key signed by the secret key of the user U as set forth in block 1208. The bank B identifies the user U using the password zu i and verifies the signed transmission of block 1208 as set forth in blocks 1212, 1216. The bank B independently computes the next value of the user password zu,i +1 and sends the public key of the user U back to the user U signed by the secret key of the bank B as shown in block 1220. In block 1224 the user U verifies the signed transmission of block 1220. The user U independently computes the next password, zu,i+1, in block 1228.
The withdrawal protocol required for this procedure is similar to the withdrawal protocol 200 with a few important differences. In order to permit payment of the cash amount payment_value to the payee S by the user U, the payee S chooses a random value γs as shown in block 1304. The payee S also computes ps = H(γs, counters , S) as shown in block 1308. The payee S sends ps and token_signP as part of a challenge to the user U in block 1312. The purpose of this challenge by the payee S is to prevent replay attacks and to confirm to a bank Bs used by the payee S that the payee S is the recipient of the payment. The payee S then increments its counter in block 1312. The reason the value counter and the identity of the payee S are hidden is so that the recipient v of a further transfer of the electronic cash cannot identify the payee S . The user U and the payee S use an authenticated key exchange protocol to agree on a mutual secret encryption key prior to performing the anonymous transfer payment protocol 1300. They then communicate the payment process in private so that eavesdroppers can not recognize the signing keys coin_signP, token_signP if they later appear in other transfer protocols performed in accordance with the present invention.
When the payee S later sends the payment protocol and the random value γs to the bank B, as shown in block 1404, the bank B verifies the payment protocol and ργ as shown in blocks 1408, 1412. The bank B increments its counter and verifies that the withdrawal is legitimate in block 1416. The bank B also verifies that the electronic coin being deposited is not overspent as shown in block 1420.
Referring now to Fig. 15, there is shown the anonymous transfer protocol 1500 of the present invention. The anonymous transfer protocol 1500 may be used to permit the anonymous transfer of an electronic coin from a payee S to a third party N in the electronic cash system of the present invention. The transfer of a previously spent electronic coin in the transfer protocol 1500 is similar to the first payment of an electronic coin protocol set forth in the anonymous transfer electronic cash payment protocol 1300 and others described hereinabove. In the annoymous transfer protocol 1500 random value γv is generated as shown block 1504. A value of ρν is determined in block 1508. The value ρν and a token are sent to the payee S in block 1512. In the anonymous transfer protocol 1500 the payee S computes and uses a token in place of a regular electronic coin as shown in block 1516. The payee S then appends information from the third party M and transmits to the third party M in block 1520. The third party M then performs the verifications of blocks 1528-1540 of anonymous transfer protocol 1500.
Referring now to Fig. 16, there is shown the anonymous deposit protocol 1600. The anonymous deposit protocol 1600 may be used to deposit an electronic coin which was anonymously transferred according to the anonymous transfer protocol 1500. In the anonymous deposit protocol 1600 the third party M transmits to the bank B a record of the anonymous payment and the random value γv, as shown in block 1604. The bank B then verifies that the transfer protocol 1500 was executed properly by the payee S as shown in block 1608. In block 1612 the bank B verifies ρ v = H (γv, counterv' Υ), which was received as part of the transmission of block 1604 and verifies the withdrawal and independently increments counterB v as shown in block 1616. In block 1620 the bank B determines that the electronic cash was not overspent.
Brickell, Gemmell, and Kravitz have proposed electronic cash systems which provably hide the identity of a user U in electronic financial transactions with the exception that the government G can trace the spending of the user U with certainty. See, for example, "Trustee-Based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change," Proceedings of the Sixth Annual ACM-SIAM Symposium on Discrete Algorithms, (1995), pp. 457-466. This system and method permits the government G to determine the recipient of the electronic cash paid by the user U aad the amount paid. It will be understood by those skilled int he art that the following descriptions enable inventions not necessarily shown in the representations of Figs. 1-16. It will also be understood that the following descriptions describe inventions which may be used in connection with the protocols of Figs. 1-16.
Tracing by the government G in the further electronic systems of Brickell, Gemmell and Kravitz is possible only with the cooperation of several appointed trustees Ti. The appointed trustees Ti are key-escrow agents in these systems. The primary disadvantage of systems of this type is that the systems may not be very efficient. They tend to require relatively large amounts of memory space for the banks to store the electronic coins and other information. They also tend to require a relatively large amount of processing power to generate and spend electronic coins. Furthermore, they rely on blind signature technology, such as that of Brands, or of Franklin and Young. In the system and method of the present invention trustee-based tracing is incorporated into protocols similar to those taught by Brands as referred to herein. Thus, this feature of the present invention may be understood to be an improvement of the protocols of Brands which allows for trustee-based tracing. There is no need for any tamper-resistant devices or any inconvenience to the user U in this method. The security of all parties in this method is based only upon cryptographic assumptions. Trustees T1 and T2 participate in an interactive process during the setup protocol when they conduct proofs of knowledge of a representation for each value fk wherein k indexes the electronic coin withdrawn by the user U and each electronic coin is understood to have a different value fK .
Let p, q be large primes such that g| (p-1) and let ⊂Z*p be the subgroup of order q. Let g, g1 , -g2, g3 , g4 , d be generators of ξ randomly chosen by the bank B. The values hi= gαi are information published by the bank B for verifying authenticity of the electronic coins wherein the index i refers to the denomination of the electronic coin. Knowledge of -fallows the bank B to mint coins of denomination i. The setup, withdrawal, and payment protocols are extensions of basic setup, withdrawal and payment protocols taught by Brands.
In the new setup protocol, the user U gives the trustees T1 and T2 information which allows them to link any payment involving each electronic coin to its withdrawal. This information is the combined knowledge of U's representation of the value fk=g3γ3,k g4γ4,k. The trustees T1 and T2 prove to the government G that they know the representation for this value of fk.
In the setup with trustees T1 and T2 the user U generates random u1, u2 and sends Iu=g1 u2g2 u2 to the bank B. The bank B associates Iu with the identity of the user U, IDu, chooses a random αi for each coin denomination i and broadcasts g and hi=gαi. If N is an upper bound on the number of electronic coins which the user 17 withdraws, the user U chooses {γ3,k, γ4,k) for k=1 to Ν ε εr Zq. For each k, the user U randomly splits γ3, k=Sk1,1 + Sk2,1 Υ4,k=Sk1,2 + Sk2,2 mod (q) and sends Sk 1, 1, Sk 1,2, to the trustee T1 and Sk 2,1, Sk 2,2, to the trustee T2. For each value of k, the user U sends fk=g3Υ3,kg4γ4,k to the bank B. For each value of k, the trustees T1 and T2 prove combined knowledge of a representation of fk to the bank B relative to g3 and g4. The new withdrawal protocol is very similar to a protocol taught by Brands except that m=Iudfk.
The underlying idea of the protocol of Brand is that the bank B provides the user 17 with a blind signature that is a tuple (A,B,z',a'b',r') . This tuple satisfies the equations gr=hH(m',z',a',b',A)a'mod(p) and m'r'=z'H(m', z',a',b',A)b'mod(p). If H is a one-way collision-free hash function, it is believed to be hard to create a tuple of this form without finding the discrete log of h . The features of Brands referred to may be found, in particular, in S. Brands, "Electronic Cash Systems Based on the Representation Problem in Groups of Prime Order," Preproceedings of CRYPTO 93 which is incorporated by reference herein. Furthermore, because the signature is blinded the tuple is uniformly distributed among all such tuples when one is given only the view of the conversation as seen by the bank B.
When performing a withdrawal with trustees
T1 and T2 for the denomination i for the kth withdrawal by the user U, let h = hi , α=αi. The user U proves knowledge of a representation of Iu=g1 u1 g2 u2 mod (p) to the bank B. The bank B then chooses εr Zq of, sets m = Iudf k and sends z=mα a=gw, b = mw to the user U. The user U chooses sεr Z*q sets m' = ms, z ' = zs, chooses x1 , x2, x4, x5 , εr Zq, and sets y1 = u1s - x1
y2 = u2s - x2 mod ( q)
y4 = γ4 , ks - x3
y5 = s -x5 mod (q)
where A=g1 x1 g2 x2 g3γ3,ks g4 x4 dx5 and B=g1 y1 g2y2g4y4dys. The user U chooses u, vε∑rz*q, sets a' = augv, b' = bsu(m')v, H(m',z',a',b',A) and sends c = c ' /u to the bank B. The bank B sends r = αc+w mod(q) to the user U. The user U then verifies gr' = hca,mr = zcb mod(p), sets r' = ru+v mod (p) and sets signβ(A,B)-=(z,,a',b,,r').
In this payment protocol, the user U is forced to reveal the value r3 = γ3,ks. Later, if the trustees T1 and T2 give the government G the value γ3 , k from the execution of the withdrawal protocol and the government G has the values m', r3 = r3, ks from an execution of a payment protocol, then the government G can compute s and Iu = m's(-1)/fk mod(p), thereby linking the payment with the withdrawal.
When performing a payment with the trustees T1 and T2, the user U sends A, B, signβ (A, B) = (z ' , a ' ,b' , r' ), r3 = γ3,ks mod(q) to the payee S . The payee S then verifies that AB ≠ 1 and signβ (A, B) . The payee S then sends c1 = H (IDs, time, r3, A, B) to the user U. The user U sends r1 = x1+c1y1 mod(q),r2 = x2+c1y2, r4 = x4+c1y4, and r5 = x5+c1y5 to the payee S . The payee S verifies g1 r1, g2 r2, g3 r3, g4 r4 drs= ABc1 mod(p). In the deposit protocol, the payee S sends a transcript of the payment protocol to both the bank B and the government G.
The procedure which the government G can use to trace multiple spenders is substantially similar to that set forth in the basic protocols of Brands . When tracing with multiple spenders the bank B has records of an electronic coin spent two times, with two different challenges, β, β ' . To identify the user U, the bank B uses the two sets of responses (r1, r2, r3) and (r'1,r'2,r'3) and computes
Z2 = (r3-r'3)/(β-β1)
z1 = r3 - βz2,
s = z1 + z2
x2 =(r'-r'1)/(β-β1)
x1 = r1 - βx2
u1 = x1 + x2
y2 = (r2 - r2) / (β-β1)
y1 = r2 - βy2
u2 = y1 + y2
Iu = g1 u1 g2 u2.
When presented with a court order the trustees T1 and T2 provide the government G with the means required to trace the user 17.
In the second protocol, the trustees T1 and T2 do not provide the government G with the value γ3,k. Instead, they determine only whether M1r3 (-1) = (Iudfk) γ (-1) 3,k by attempting to prove knowledge of a representation of Iudfk in terms of the single generator m'r3 (-1).
To trace with the trustees T1 and T2 the government G asks the trustees T1 and T2 for all sets of withdrawal values {s i,j} i,jε{1,2} for the user U.
For all withdrawals they compute γ3,k = s1, 1+s1 ,2 mod(q) and search the database of payment transcripts for Iudfkγ( -1)3,k. In this manner the electronic coin of the user U is determined.
In trace-one payment, the government G determines whether a particular payment is previously made by a user U. To perform this operation let {sk i,j} i=1,2;j-1,2;k=1,...,N be the shares given by to the user ϋ to the trustees T1 and T2 during the N executions of the withdrawal protocol performed by the user U. The government G obtains a court signature for the payment in question and sends m', r3,Iu, signc(m',r3,Iu) to the trustees T1 and T2. For each value fk the trustees T1 and T2 attempt to prove combined knowledge of a representation of ludfk relative to m'(r3(-1)mod(q)) using their knowledge of sk 1, 1 and sk 1,2. If the trustees T1 and T2 succeed, the government G assumes that the electronic coin involving m' was spent by the user U.
The above protocols are believed to preserve the protections of Brands against counterfeiting and multiple spending. Furthermore, the values A,B,z',a',b',r',r1,r2,r3,r4,r5,c appearing in the payments of the coins transmitted by a user U are completely independent from the values Iu,fk,w, m, z,a,b,c,r and the values appearing in the trustees' proof of knowledge of a representation of fk appearing in the withdrawals of the user U. Therefore, without help from all the trustees T1 and T2 the electronic cash of the user U is believed to be information- theoretically anonymous when using this method. If the user U cannot forge Schnorr signatures and if the hash function, H, is designed correctly, then it is infeasible for the user U to prevent the trustees T1 and T2 from linking withdrawals to payments. If the user U does not reveal the representation Iu= g1 w1 g2 w2, then the government G even with the help of all the trustees T1 and T2 could successfully claim that an honest user U made a payment it did not make only if the government G or the trustees T1 and T2 can compute discrete logs. If there is a legitimate payment such that an honest government G is able to link withdrawals from both a user u and a user
Figure imgf000053_0002
to that payment, then the user U and the user
Figure imgf000053_0001
can combine their information to get a non-trivial representation of 1 relative to generators g1,g2,g4,d. This means that dishonest users cannot create false links between withdrawals and payments.
By distributing the power to trace the trustee-based cash systems described hereinabove are designed to improve public confidence in the privacy preservation goals of electronic cash systems while assuring the government G that it can reliably monitor suspected criminal activity under court order. One trouble with relying solely on human trustees such as trustees T1 and T2 is that it is seemingly impossible to guard against the case where all the trustees misbehave and conspire with a corrupt government G to trace the spending habits of honest citizens. Thus, the inventive method includes a solution which guarantees the innocent user U at least notification that it is being traced even if the government G and all human trustees T1 and T2 conspire against the user 17. This solution includes an electronic trustee TE in which both the government G and the user U may feel confident in placing their faith. The trustee system set forth is described in terms of electronic cash. However, it will be understood by those skilled in the art that similar trustees may be used in the context of other types of key-escrow systems.
Thus it will be understood that certain guarantees are required for the various parties involved to have confidence in electronic cash systems such as those described herein. One guarantee is that the user U wants to be sure that if it is being traced it will be notified of this fact within some specified amount of time. With electronic cash the knowledge of a trace available to a user it does not hamper the tracing of its past transactions. Consequently, the user community can benefit from timely notification of cash traces. This is unlike the recovery of plaintext wiretapped communications which is the province of CLIPPER. Under current law, wiretaps are not allowed without prior court authorization even if the wiretappers cannot yet decipher the intercepted traffic. Therefore, law enforcement cannot legally decrypt conversations that take place before a wiretap is approved.
Another requirement is that the government G needs to be certain that it can access each share of the key of the user U as held by an electronic trustee TE. A solution to this problem requires both parties to build separately a different part of a two- part electronic trustee. The government may build an inner part of the electronic trustee TE without knowledge of the eventual user U corresponding to the electronic trustee TE . This part should be read-proof against the user 17. The entire inner part may be embedded in the latest high-tech tamper-resistant material. By read-proof it is intended that the user U cannot alter any component of the inner part without erasing the secret signature key, SigS T, of the inner part and that the user U cannot read the value of Sigs T . The government G extracts the corresponding value of SigPT from the inner part prior to surrendering control of the inner part to the user U.
In addition to securely maintaining Sigs T, the inner part accepts as input the private key θT corresponding to the trustee public key E-p into a register which can be loaded exactly once by the outer part and is non-erasable but readable. This is the register which the government G needs to read from each electronic trustee TE to enable a trace of spending by the user U. In order to ensure a match between the value of θT as held by the electronic trustee TE after installation by the user U of the outer part, and the circulated value of θΦ, certain precautions must be taken. After verifying that θT=ET -1 for the supplied or computed value of ET, Sigs T (ET ) is generated by the inner part, where no value ET', distinct from the value of ET for which the corresponding value of θT is loaded into permanent memory, will be signed. To verify that the user U has placed the intact inner part inside the electronic trustee TE random challenges to be signed using SigsT are administered by the government G, and are limited in number to the preset value in the inner part.
The outer part of the electronic trustee TE, built by the user U or its specified vendor, monitors the output of the SigsT function and controls the transmissions of the electronic trustee TE in order to eliminate leakage with respect to the value of θT . In order to electronically notify the user U if an attempt has been made to recover the value of θT from the electronic trustee TE, while protecting the government G from false claims of unauthorized access to θT, the following procedure is specified. The outer part generates a pulse key pair, (KpulseT s, KpulseT p), where the public key KpulseT P is registered with a third party prior to deployment of the electronic trustee TE.
Figure imgf000056_0001
seT s is used to sign periodic sequenced messages, verifiable using KpulseT p, which effectively affirms that no attempt has been made to retrieve β-p, since the user 17 can implement the outer part so that KpulseT s is automatically erased upon intrusion of the electronic trustee TE .
After the government G is satisfied that nothing has been introduced into the outer part which can later obliterate θT from the retrievable memory of the inner part, the electronic trustee TE is coated under user and government supervision. It is in the legitimate interest of the user U to apply a coating which alters upon tampering and is impossible to reproduce exactly or to predetermine. The government G assures itself that the outer part and the coating are constructed so that the coating cannot be modified spontaneously or from within. A digitization of the coating is signed by the KpulseT S key of the outer part. The user U can design and implement the KpulseT S function so as to thereafter accept only internally generated inputs. Alternatively, the digitized value of the coating is signed by the user 17 or its legal representative. The signed version of the coating value is supplied to the government G. The electronic trustee TE is from then on, held securely under government control.
The following addresses the problem of the user U wishing to make an anonymous purchase from a payee S but having incorrect change. It is assumed that the payee S in this system has a computer link to a bank B but that the user U does not wish to identify itself to the bank B in order to prevent the bank B form associating it with the payee S . It is also assumed that the user U has Y dollars in coins and that the user U wishes to make a purchase worth X < Y dollars.
A protocol is therefore presented hereinbelow which allows a user U to present anonymously a set of electronic coins worth Y dollars to the bank B and receive in return another set of electronic coins also worth Y dollars but in different denominations. The user U chooses the denominations in such a way that it can combine the returned electronic coins to get X dollars.
When getting anonymous change the user 17 wishes to give the bank B an amount equal to Y dollars in coins of different denominations. The user 17 uses the payment protocol to pay the y dollars in electronic coins to the bank B without revealing IDu and tells the bank B the desired denominations of the change. The bank B checks that the requested coins total Y dollars. Let m 'old be a value from one of the coins that the user U paid. For every electronic coin to be given out as change the bank B uses the appropriate value of hi . For complete anonymity the bank B and the user U use value m'new = m 'old for each new electronic coin withdrawn. For trustee-based tracing, the user U generates a new value fnew = gΥ3 344 for each new coin and sends to the trustees shares of 7374. The user U and the bank B use the value m'new = m' oldfnew in the withdrawal of that electronic coin. The above protocol, when added to either the basic protocols of Brands or to the trustee-based system, maintains the following properties. The augmented system is secure against counterfeiting and multiple spending by a user U. Without help from all the trustees, the values appearing in the payments of electronic coins transmitted by the user U are completely independent from the values appearing in the withdrawals. The trustees may then combine their information and trace both the original coins of the user U and the coins given as change.
Unlike prior art RSA signature schemes, the Digital Signature Algorithm, as embodied in the Digital Signature Standard, utilizes randomness in the signing process. Furthermore, unlike the El Gamal signature scheme, the Digital Signature Algorithm apparently does not transmit enough information in its signatures to allow recovery of the public key. For these reasons the functionality of the Digital Signature Algorithm may be efficiently extended beyond a straight forward digital signature mechanism in order to provide (1) sender anonymity, (2) transaction security, and (3) database security. Thus with respect to (1) it is possible to eliminate the need for an encryption function for the purpose of hiding identities and preventing the linking of transactions to the same individual. By avoiding the use of encryption, while maintaining the ability to negotiate unlinkable anonymous transactions, the present invention which extends the operation of the Digital Signature Algorithm provides the ability to apply cryptography in order to secure applications such as electronic commerce without relying on the prior art found in several patents on public-key cryptography. Furthermore, it is possible to simultaneously allow the legitimate recipients to access the database entries corresponding to the identity of sender.
Additionally, with respect to (2) it is possible to prevent , the acceptable replay of transactions by anyone other than the legitimate transaction originator, even if given read-access to the hardware-secured database. With respect to (3) it is possible to prevent modification of the user- specific information held in the hardware-secured database without authorization transmitted by the user U.
In this method the user 17 generates a private key signs u denoted by xu and a corresponding public key signPu = gxu mod p also denoted by yu. In this process the Digital Signature Standard signature is also transmitted and Zu,i+1 is computed as an extension of the process of verifying the signature of the Digital Signature Standard. The initial value of zu ,i is randomly or pseudorandonmly generated. The value signPu is stored under the address zu ,i in the central database and is not made public. In the signing and transaction transmittal the user U appends Zu , i to a message m, and signs SHA (m,zu ,i ) , using the Digital Signature Standard. To obtain sender anonymity as specified in (1) SHA (m) would suffice. In this method SHA is the secure hash algorithm function specified in the Secure Hash Standard, as understood by those skilled in the art. In this method, zu ,i = SHA(yu su (-1)rumodqmodp) , where [ru, su) constitutes the Digital Signature Standard signature transmitted as part of the previous transaction transmittal, if any. Otherwise, the initial value of zu ,i is used. The signals m, zu ,i , and the current Digital Signature Standard signature as previously described are transmitted.
In the transaction receipt and verification the received zu ,i is used to access signs u in the database and to verify the current signature of the Digital Signature Standard as applied to the message m and zu ,i . If the signature is valid, the new value of the user password, z-u, i+1 , is computed as SHA(yu su(- l)rumod(q)mod(p) ) , where SHA(yu (su-1) rumod (q) mod (p) was used during the current signature verification. The new value zu , i +1 overwrites the previous value zu , i .
Thus with respect to (1) above, without knowledge of y's, z's are not partitionable or traceable to the transaction originators. With respect to (2), above, unauthorized replay is prevented because zu changes each time and must be signed for the transaction to be acceptable. With respect to (3) above, if the signature is found to be valid, the user U data corresponding to yu and addressed by zu can be modified within the hardware secured database. It will be understood by those skilled in the art that a more general function of yu, su and ru may be substituted in the definition of
Zu. The following protocols are designed to be used in settings wherein most of the transactions may usually be conducted on-line. In these situations a bank B may occasionally lose contact with the system for a limited period of time. When this happens the off-line aspects of the system enable most transactions to take place during the downtime. One of the primary advantages of this system is that it does not use public key cryptography and it thus avoids the need to license or purchase such patented technology.
For each payee S, the bank B sets a limit on the number of outstanding coins for the payee S, i.e., those S-designated coins which are not yet expired and are still in circulation. When the system of the present invention is online, this does not matter because customers wishing to make payments to the payee S can bring coins into and out of circulation in the same transaction. It will be understood that xεuS indicates that element x is chosen uniformly at random from the set S. Additionally, let the user U be an arbitrary system user, let B be the bank, let the payee S be a seller of goods, and let C be the customer. In the initial set-up the user U acquires the software and provides its identification to the bank B. The bank B provides account_numberu to the user U which then provides the bank B with the random seed r0 U'B from the software of the user U that will be used for correspondence between the user U and the bank B. The bank B enters ( U, account_numberu,r0 U'B) into the bank database.
In the coin set-up protocol the customer C uses a one-time identification to identify itself to the bank B and requests g coins from the bank B which are spendable to the seller S . The bank B responds with an encrypted and authenticated message of acknowledgment. At such time that g plus the number of outstanding coins for the seller S is less than or equal to the maximum allowable number of outstanding coins for the seller S, the bank B randomly chooses a set 0 = {coins i } iε{ 1 , . . . , q} of coins of appropriate denominations, chooses r0 C,Sεu {0,1}k and sends
(S,θ,r0 C'S), encrypted and authenticated to the customer C. The bank B sends {g (coinis) }iε{1, ...,q} r0 C'S, as well as acknowledgment of the last deposit to the seller S. All transmissions are sent authenticated. The signal r0 C'S is transmitted encrypted as well. In order to perform the protocol ∑coin for the payment of the amount value1 the customer C chooses Cθ such that ∑ (coini s) =value1. The customer C sends to the seller r and addressc which are authenticated using r0 C'S. The value addressc can also be encrypted for privacy using roC,S. The seller S verifies the authentication, verifies that ∑(coini s) =value1, checks S's list of coin hash values {g(coini s)} coiniSεI, verifies that T contains no repeats, removes the set {g(coini s)} coinigei from S's list of coin hash values and, if appropriate, sends the merchandise to addressc. In the protocol for the deposit of the amount value1 the payee S identifies itself to the bank B and sends T to the bank B. Let H2 be a one-way hash function mapping into k bits. Given a string x, and indices i < j let x {i,...,s} be the bits xi through xj, inclusive. In the following protocols, X is the party that sends encrypted messages, identifiers and authenticated messages. In general, the encryption, identification, and authentication can be sent by either X or Y, in any combination.
In the encryption and one-time identification protocols let X and Y both know a k-bit session key ri X'Y. The value r0 X'Y is a random seed that they agree upon initially. In order to identify itself to Y , X sends the ith password: [ri x'y] {2K/3 +1 ...,k) to Y. For X to send a message miε (0, 1) k/6 to Y, X chooses rεu{0,1}k/6 and sends (mi | r)⊕ [rx,y] to Y. Y then recovers (m-jjr) and X and Y create a new session key ri+1 x,y = H2(r,X,y,r), and set i←i+1.
In the case of a one-time authentication the following protocol may be used. At the same time as sending a message mi, X send the authentication
H2([rix,y] {(k/3)+1,...,2k/3},mi,0) to Y. Y verifies the authentication message and sends the authentication H2( [rix'y] {k/3+1,...,2k/3},mi,1) to X. X verifies Y's authentication message.
It will be appreciated by those skilled in the art that changes may be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood therefore, that this invention is not limited to the embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.

Claims

What is Claimed is :
1. In an off-line electronic cash system having an electronic coin, a bank B, a user U having an account at said bank B and a payee S, a method for performing an electronic cash transfer independently of public key cryptography, comprising the steps of:
(a) withdrawing said electronic coin from said bank B by said user U; (b) storing an electronic record of said electronic coin by said bank B;
(c) paying said electronic coin to said payee S by said user U;
(d) depositing said electronic coin with said bank B by said payee S; and
(e) determining that said electronic coin is spent in accordance with the depositing of step (d).
2. The off-line electronic cash transfer method of claim 1, comprising the further step of deleting said record by said bank B in response to the determining of step (e).
3. The off-line electronic cash transfer method of claim 2, comprising the further step of determining a further deposit of said electronic coin after the said deleting.
4. The off-line electronic cash transfer method of claim 3, comprising the further step of determining said user U in accordance with said determining of said further deposit.
5. The off-line electronic cash transfer method of claim 1, wherein the user has a user password zu , 1 and the value of said electronic coin is wi thdrawal_value and step (b) comprises the further steps of : (f) generating by said user U a key pair ( coin_signP, coin_signs) wherein said coin_signP is a public signing key and said coin_signs is a secret signing key;
(g) transmitting (zu,i, coin_signP, wi thdrawal_value) by said user U to said bank B;
(h) verifying the transmission of step (g) by said bank B;
(i) deducting wi thdrawal _value from said account of said user U; and (j) transmitting ( coin_signP, withdrawal_value) to said user U by said bank B.
6. The off-line electronic cash transfer method of claim 5, wherein the transmission of step (j) is signed by a secret signature key signs B of said bank B.
7. The off-line electronic cash transfer method of claim 5, comprising the further step of verifying the transmission of step (j) by said user ϋ using a public signature key signPB of said bank B.
8. The off-line electronic cash transfer method of claim 5 wherein the transmission of step (g) is signed by said user U using a secret signature key signs u of said user 17.
9. The off-line electronic cash transfer method of claim 7, wherein the transmission of step (j) is signed by said bank B using said secret signature key signs B.
10. The off-line electronic cash transfer method of claim 1, further comprising the steps of: (k) transmitting by said user ϋ to said payee S a representation of a payment value and a representation of said electronic coin provided to said user ϋ by said bank B in step (a); and (l) verifying said electronic coin by said payee S.
11. The off-line electronic cash transfer method of claim 10, wherein said payee S has a challenge counter and said payee S transmits said challenge counter to said user U before the transmitting of step (k).
12. The off-line electronic cash transfer method of claim 11, wherein the representation of step
(k) is determined by said challenge counter.
13. The off-line electronic cash transfer method of claim 10, wherein the representation of step
(k) is signed by said user U using a secret signature key coin_signs.
14. The off-line electronic cash transfer method of claim 10, wherein said electronic coin is signed by said bank B using a secret signature key signs B.
15. The off-line electronic cash transfer method of claim 1, wherein step (d) comprises sending a record of the paying of step (c) by said payee S.
16. The off-line electronic cash transfer method of claim 11, wherein step (d) comprises verifying said challenge counter by said bank B.
17. The off-line electronic cash transfer method of claim 13, wherein step (d) comprises verifying said representation of step (k) by said bank B.
18. The off-line electronic cash transfer method of claim 11, wherein step (d) comprises incrementing said challenge counter by said bank B.
19. The off-line electronic cash transfer method of claim 1, further comprising a user password zu , i , wherein said user password zu , i is an indexed password and said user U and said bank B separately determine a further indexed password zu,i+1 in accordance with said indexed password zu, i.
20. The off-line electronic cash transfer method of claim 19, wherein said further indexed password zu, i+1 is determined in accordance with separate information shared by said user U and said bank B.
21. The off-line electronic cash transfer method of claim 1, wherein a plurality of deposits occur according to step (a) before the determining of step (e).
22. The off-line electronic cash transfer method of claim 1, wherein said system includes first and second differing banks and the withdrawing of step
(a) is performed from said first bank and the depositing of step (d) is performed with said second bank.
23. The off-line electronic cash transfer method of claim 1, wherein said system includes first and second payees and said first payee receives said electronic coin in step (c) and transfers said electronic coin to said second payee and the depositing of step (d) is performed by said second payee.
24. The off-line electronic cash transfer method of claim 1, wherein an identification of said payee S is embedded in said electronic coin and only the identified payee S can perform the depositing of step (d).
25. The off-line electronic cash transfer method of claim 1, wherein said method is performed independently of public key cryptography.
26. The off-line electronic cash transfer method of claim 1, wherein said method is performed using cryptography which is only symmetric-key cryptography.
27. In an off-line electronic cash system having an electronic coin, a user U, a payee S and a bank B, a method for performing an electronic cash transfer, comprising the steps of: (a) determining a representation of an identification of said user U;
(b) embedding said representation of said user 17 in said electronic coin;
. . (C) transmitting said electronic coin having said embedded representation by said bank B;
(d) receiving a representation of said com transmitted in step (c); and
(e) determining said user U in accordance with the representat ::ion received in step (d).
28. The off-line electronic cash transfer method of claim 27, wherein the representation of step (a) comprises the public key signs u of said user U .
29. The off-line electronic cash transfer method of claim 27, wherein said identification of step (a) comprises a bank account number of said user U .
30. The off-line electronic cash transfer method of claim 27, wherein the representation of step
(a) further comprises an identification of said bank
31. The off-line electronic cash transfer method of claim 27, wherein the determining of step (e) is performed by said bank B.
32. The off-line electronic cash transfer method of claim 31, wherein the determining of step (e) is performed by a party other than said bank B.
33. The off-line electronic cash transfer method of claim 27, comprising the further steps of: (f) paying said electronic coin by said user 17 to said payee S;
(g) transferring said electronic coin from said payee S to a further payee; and
(h) depositing said electronic coin by said further payee with said bank B.
34. The off-line electronic cash transfer method of claim 27, wherein said system includes first and second differing banks and the transmitting of step (c) is performed by said first bank and the receiving of step (d) is performed by said second bank.
35. The off-line electronic cash transfer method of claim 27, wherein an identification of said payee S is embedded in said electronic coin and only the identified payee S can deposit said coin with said bank B.
36. An electronic cash transfer method for withdrawing and transferring an electronic coin in an off-line electronic cash transfer system having a bank B , a user U and a payee S , comprising the steps of:
(a) providing a user password zu,i to said user U; (b) transmitting said user password zu,i and a withdrawal amount to said bank B by said user U without encryption of said withdrawal amount;
(c) identifying said user U by said bank B in accordance with said user password zu,i; (d) providing an anonymous electronic coin in accordance with the transmitting of step (b) and the identifying of step (c);
(e) transmitting said anonymous electronic coin to said user U; (f) receiving said anonymous electronic coin by said bank B; and
(g) determining said user U by said bank in accordance with said received anonymous coin.
37. The electronic cash transfer method of claim 36, wherein said user password zu,i is a one- time password which is assigned a plurality of values and each value of said plurality of values is assigned only once with high probability.
38. The electronic cash transfer method of claim 37, wherein said user password zu,i is an indexed password.
39. The electronic cash transfer method of claim 37, wherein a next value, zu,i+1, of said user password zu,i is determined in accordance with a public key signature.
40. The electronic cash transfer method of claim 39, wherein said next value is determined independently by each of said user U and said bank B.
41. The electronic cash transfer method of claim 40, wherein step (b) is performed in the open.
42. The electronic cash transfer method of claim 40, where the identifying of step (c) is performed in accordance with said independently determined next values of zu,i+1.
43. The electronic cash transfer method of claim 36, wherein said user 17 is provided with a user public key coin_signP further comprising the step of transmitting said user public key coin_signP by said user 17 to said bank B.
44. The electronic cash transfer method of claim 43, wherein said user ϋ is provided with a user secret key coin_signs further comprising the step of signing said user password zu,i, said user public key coin_signP and said withdrawal value by said user U with said user secret key prior to transmission to said bank B.
45. The electronic cash transfer method of claim 44, wherein said coin_signP and coin_signs are a key pair.
46. The electronic cash transfer method of claim 45, wherein said key pair is generated by a digital signature standard.
47. The electronic cash transfer method of claim 45, wherein said key pair is generated by RSA.
48. The electronic cash transfer method of claim 36, wherein the transmission of step (b) is performed in the clear.
49. The electronic cash transfer method of claim 36, wherein step (e) is performed in the clear.
50. The electronic cash transfer method of claim 49, wherein step (f) is performed in the clear.
51. The electronic cash transfer method of claim 46, wherein step (d) is followed by the step of transferring said electronic coin to said payee S and said payee S is prevented from determining said user U in accordance with said electronic coin.
52. The electronic cash transfer method of claim 51, wherein the step of transferring said electronic coin to said payee S is performed in the clear.
53. The off-line electronic cash transfer method of claim 36, wherein said system includes first and second differing banks and the transmitting of step (e) is performed by said first bank and the receiving of step (f) is performed by said second bank.
54. The off-line electronic cash transfer method of claim 36, wherein said system includes first and second payees and said first payee receives said electronic coin transmitted in step (e) and transfers said electronic coin to said second payee and deposits said electronic coin with said bank B.
55. The off-line electronic cash transfer method of claim 36, wherein an identification of said payee S is embedded in said electronic coin and only the identified payee S can deposit said electronic coin with said bank B.
56. An electronic cash transfer method for withdrawing and transferring an electronic coin in an off-line electronic cash transfer system having a non- minting entity A, a minting entity B, a user U and a payee S, comprising the steps of: (a) minting said electronic coin by said minting entity B; (b) transferring said electronic coin from said minting entity B to said non-minting entity
A;
(c) withdrawing said electronic coin from said non-minting entity A by said user U;
(d) transferring said electronic coin by said user U to said payee S;
(e) providing a payment record in accordance with said transferring of step (d); and
(f) determining said user U in accordance with said payment record by said non- minting entity A and said minting entity B only in cooperation with each other whereby cooperation of said minting entity A and said minting non-entity B is a necessary and sufficient condition for said determining of said user U.
57. The electronic cash transfer method of claim 56, wherein step (b) comprises withdrawing said electronic coin from said minting entity.
58. The electronic cash transfer method of claim 56, wherein said user U anonymously sends the information which the minting entity B requires in order to sign said electronic coin.
59. The electronic cash transfer method of claim 56, wherein step (b) comprises transferring said electronic coin by said non-minting entity A to said user U, and said electronic coin is previously signed by said minting B and said non-minting entity A is unable to read said electronic coin.
60. The electronic cash transfer method of claim 58, wherein said user ϋ is provided with a public encryption key and the transferring of step (b) comprises encrypting said information by said minting entity B using said public encryption key of said user U.
61. The electronic cash transfer method of claim 60, wherein said encrypting comprises encrypting the result of a hash function.
62. The electronic cash transfer method of claim 60, wherein said public encryption key is a one time public encryption key.
63. The electronic cash transfer method of claim 61, comprising the further step of transmitting said encrypted information to said non-minting entity A.
64. The electronic cash transfer method of claim 58, wherein said user U is provided with a public encryption key and step (c) comprises the sending of the encrypted information of step (b) by said non-minting entity A to said user 17.
65. The electronic cash transfer method of claim 60, further comprising the step of decoding said encrypted message from said non-minting entity A by said user U for verification.
66. The off-line electronic cash transfer method of claim 56, wherein said system includes first and second differing further banks and the withdrawing of step (c) is performed from said first bank and said electronic coin is deposited with said second bank.
67. The off-line electronic cash transfer method of claim 56, wherein said payee S receives said electronic coin in step (d) and transfers said electronic coin to a further payee and said further payee deposits said coin with a bank.
68. The off-line electronic cash transfer method of claim 56, wherein an identification of said payee S is embedded in said electronic coin and only the identified payee S can deposit said electronic coin with said non-minting entity A.
69. An electronic cash transfer method for withdrawing and transferring an electronic coin in an off-line electronic cash transfer system having a bank
B, N non-minting entities, a user U and a payee S, comprising the steps of :
(a) withdrawing an electronic coin from said bank B;
(b) transferring said electronic coin by said user U to said payee S;
(c) receiving of said electronic coin by a non-minting entity in accordance with said received coin of said N non-minting entities.
(d) determining said user ϋ in accordance with said received coin by M of said N non- minting entities in cooperation with each other in accordance with said received coin wherein M < N.
70. The electronic cash transfer method of claim 69, wherein said electronic cash transfer system has a system initialization for bringing said system on line and thevalue of M is determined prior to said system initialization and is unvarying thereafter.
71. The off-line electronic cash transfer method of claim 69, wherein said system includes first and second differing banks and the withdrawing of step (a) is performed from said first bank and the receiving of step (c) is performed by said second bank.
72. The off-line electronic cash transfer method of claim 69, wherein said system includes first and second payees and said first payee performs the withdrawing of step (a) and transfers said electronic coin to said second payee and the receiving of step
(c) is performed from said second payee.
73. The off-line electronic cash transfer method of claim 69, wherein an identification of said payee S is embedded in said electronic coin and only the identified payee S can deposit said electronic coin with said bank B.
74. In an electronic transaction system having a user U, an entity G and a set of trustees Ti, a method for guarding a secret key θt and notifying said user U when said entity G and trustees of said set of trustees Ti cooperate to trace a transaction performed by said user U, comprising the steps of: (a) building a first part of an electronic trustee by said entity G wherein said first part contains an entity G secret signature key SigS T and is read-proofed against said user U; (b) extracting a corresponding public signature key SigP T from said first part by said entity G;
(c) installing a second part of said electronic trustee by said user U;
(d) receiving from said second part and verifying said secret key θT by said first part; and
(e) applying said secret signature key SigS T to a public key ET which corresponds to said secret key θT.
75. The method according to claim 74, comprising the further step of :
(f) coating said electronic trustee.
76. The method according to claim 74, comprising the further steps of : (g) monitoring by said second part all transmissions from said first part; and
(h) notifying said user U if θT is retrieved from the electronic trustee.
77. The method according to claim 75, wherein said coating is adapted to alter when tampered with.
78. The method according to claim 75, wherein step (f) comprises the further step of digitizing said coating.
79. The method according to claim 78, wherein said digitizing is signed by a secret key of said second part.
80. The method according to claim 74 comprising the further step of placing said electronic trustee in the custody of said entity G or some of trustees Ti.
81. The method according to claim 75, wherein step (f) is preceded by the step of determining that nothing capable of obliterating said secret key θT is within said electronic trustee.
82. The method according to claim 81, wherein said entity G performs said determining.
PCT/US1996/010247 1995-06-07 1996-06-07 Off-line compatible electronic cash method and system WO1996041316A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU67613/96A AU6761396A (en) 1995-06-07 1996-06-07 Off-line compatible electronic cash method and system

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US48235695A 1995-06-07 1995-06-07
US47403395A 1995-06-07 1995-06-07
US48268595A 1995-06-07 1995-06-07
US48268695A 1995-06-07 1995-06-07
US08/482,686 1995-06-07
US08/482,685 1995-06-07
US08/482,356 1995-06-07
US08/474,035 1995-06-07
US08/474,033 1995-06-07
US08/474,035 US5832089A (en) 1995-06-07 1995-06-07 Off-line compatible electronic cash method and system

Publications (2)

Publication Number Publication Date
WO1996041316A2 true WO1996041316A2 (en) 1996-12-19
WO1996041316A3 WO1996041316A3 (en) 1997-03-06

Family

ID=27541712

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/010247 WO1996041316A2 (en) 1995-06-07 1996-06-07 Off-line compatible electronic cash method and system

Country Status (2)

Country Link
AU (1) AU6761396A (en)
WO (1) WO1996041316A2 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0807910A2 (en) * 1996-05-16 1997-11-19 Nippon Telegraph And Telephone Corporation Electronic cash implementing method with a surveillance institution, and user apparatus and surveillance institution apparatus for implementing the same
EP0810563A2 (en) * 1996-05-29 1997-12-03 Nippon Telegraph And Telephone Corporation Method and apparatus for implementing hierarchical electronic cash
EP0865010A1 (en) * 1997-03-13 1998-09-16 France Telecom Secure electronic payment system and method to implement it
WO1999003079A1 (en) * 1997-07-11 1999-01-21 Ericsson Inc. Symmetrically-secured electronic communication system
FR2811452A1 (en) * 2000-07-07 2002-01-11 Thomson Multimedia Sa MICROPAYMENT TRANSACTION MANAGEMENT SYSTEM AND METHOD, CLIENT, MERCHANT AND FINANCIAL INTERMEDIATE DEVICES
CN109858281A (en) * 2019-02-01 2019-06-07 杭州云象网络技术有限公司 A kind of block chain account model method for secret protection based on zero-knowledge proof

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0507669B1 (en) * 1991-04-03 1996-06-12 France Telecom Method for electronic payment with an IC-card provided with numbered tokens; and card to implement this method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0507669B1 (en) * 1991-04-03 1996-06-12 France Telecom Method for electronic payment with an IC-card provided with numbered tokens; and card to implement this method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LECTURE NOTES IN COMPUTER SCIENCE : PROCEEDINGS ESORICS '94 (THIRD EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY),, vol. 875, November 1994, BRIGHTON-UK / SPRINGER-VERLAG,, pages 207-215, XP000565346 JA. L. CAMENISCH ET ALL.: "An Efficient Electronic Payment System Protecting Privacy" *
PROCEEDINGS OF THE FIRST ACM CONFERENCE ON COMPUTER AND COMMUNICATION SECURITY, November 1993, VA, USA, pages 102-106, XP000604414 G. MEDVINSKY ET ALL.: "NetCash: A design for practical electronic currency on the Internet" cited in the application *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0807910A2 (en) * 1996-05-16 1997-11-19 Nippon Telegraph And Telephone Corporation Electronic cash implementing method with a surveillance institution, and user apparatus and surveillance institution apparatus for implementing the same
EP0807910A3 (en) * 1996-05-16 2000-01-05 Nippon Telegraph And Telephone Corporation Electronic cash implementing method with a surveillance institution, and user apparatus and surveillance institution apparatus for implementing the same
EP0810563A2 (en) * 1996-05-29 1997-12-03 Nippon Telegraph And Telephone Corporation Method and apparatus for implementing hierarchical electronic cash
EP0810563A3 (en) * 1996-05-29 2000-01-05 Nippon Telegraph And Telephone Corporation Method and apparatus for implementing hierarchical electronic cash
EP0865010A1 (en) * 1997-03-13 1998-09-16 France Telecom Secure electronic payment system and method to implement it
FR2760876A1 (en) * 1997-03-13 1998-09-18 France Telecom SECURE ELECTRONIC PAYMENT SYSTEM AND IMPLEMENTATION PROCEDURE
WO1999003079A1 (en) * 1997-07-11 1999-01-21 Ericsson Inc. Symmetrically-secured electronic communication system
US6311171B1 (en) 1997-07-11 2001-10-30 Ericsson Inc. Symmetrically-secured electronic communication system
FR2811452A1 (en) * 2000-07-07 2002-01-11 Thomson Multimedia Sa MICROPAYMENT TRANSACTION MANAGEMENT SYSTEM AND METHOD, CLIENT, MERCHANT AND FINANCIAL INTERMEDIATE DEVICES
WO2002005226A1 (en) * 2000-07-07 2002-01-17 Thomson Licensing Sa Micropayment transaction management method, client devices, trader and financial intermediary
CN109858281A (en) * 2019-02-01 2019-06-07 杭州云象网络技术有限公司 A kind of block chain account model method for secret protection based on zero-knowledge proof
CN109858281B (en) * 2019-02-01 2020-09-18 杭州云象网络技术有限公司 Block chain account model privacy protection method based on zero knowledge proof

Also Published As

Publication number Publication date
WO1996041316A3 (en) 1997-03-06
AU6761396A (en) 1996-12-30

Similar Documents

Publication Publication Date Title
US5832089A (en) Off-line compatible electronic cash method and system
EP0873615B1 (en) Untraceable electronic cash
Brickell et al. Trustee-based Tracing Extensions to Anonymous Cash and the Making of Anonymous Change.
US6446052B1 (en) Digital coin tracing using trustee tokens
Jakobsson et al. Revokable and versatile electronic money
US6119227A (en) Methods and apparatus for authenticating an originator of a message
Franklin et al. Secure and efficient off-line digital money
Law et al. How to make a mint: the cryptography of anonymous electronic cash
US7844550B2 (en) Method and device for generating a single-use financial account number
US7853529B1 (en) Method and device for generating a single-use financial account number
JP4603252B2 (en) Security framework and protocol for universal general transactions
EP0662673B1 (en) Anonymous credit card transactions
US5956404A (en) Digital signature with auditing bits
US6073237A (en) Tamper resistant method and apparatus
US5511121A (en) Efficient electronic money
US6956950B2 (en) Computer readable medium having a private key encryption program
US6766306B1 (en) Electronic cash system
US6636969B1 (en) Digital signatures having revokable anonymity and improved traceability
US6934844B2 (en) Secure communications for a currency handling machine
WO1996041316A2 (en) Off-line compatible electronic cash method and system
EP0886248B1 (en) Method and apparatus for registration of information with plural institutions and recording medium with registration program stored thereon
Brands Electronic Cash.
Rihaczek TeleTrusT-OSIS and communication security
Valls et al. Distributed Virtual Safe-Deposit Box
Parker et al. Security requirements in banks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US US US US US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG

AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US US US US US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase in:

Ref country code: CA

122 Ep: pct application non-entry in european phase