260 likes | 386 Vues
Electronic Payment Systems 20-763 Lecture 11 Electronic Cash. Electronic Cash. Token money in the form of bits, except unlike token money it can be copied. This creates new problems:
E N D
Electronic Cash • Token money in the form of bits, except unlike token money it can be copied. This creates new problems: • Copy of a real bill = counterfeit. Copy of an ecash string is not counterfeit (or a perfect counterfeit) • How is it issued? Spent? • Counterfeiting • Loss • Fraud, merchant fraud, use in crime, double spending • Efficiency (offline use -- no need to visit a site) • Anonymity (even with collusion) No existing system solves all these problems
Online v. Offline Systems • An online system requires access to a server for each transaction. • Example: credit card authorization. Merchant must get code from issuing bank. • An offline system allows transactions with no server. • Example: cash transaction. Merchant inspects money. No communications needed.
Electronic Cash -- Idea 1 • Bank issues character strings containing: • denomination • serial number • bank ID + encryption of the above • First person to return string to bank gets the money PROBLEMS: • Can’t use offline. Must verify money not yet spent. • Not anonymous. Bank can record serial number. • Sophisticated transaction processing system required with locking to prevent double spending. • Eavesdropping!
Blind Signatures • Sometimes useful to have people sign things without seeing what they are signing • notarizing confidential documents • preserving anonymity • Alice wants to have Bob sign message M.(In cryptography, a message is just a number.) • Alice multiplies M by a number -- the blinding factor • Alice sends the blinded message to Bob. He can’t read it -- it’s blinded. • Bob signs with his private key, sends it back to Alice. • Alice divides out the blinding factor. She now has M signed by Bob.
Blind Signatures • Alice wants to have Bob sign message M. • Bob’s public key is (e, n). Bob’s private key is d. • Alice picks a blinding factor k between 1 and n. • Alice blinds the message M by computing T = M ke(mod n) She sends T to Bob. • Bob signs T by computing Td = (M ke)d (mod n) = Md k (mod n) • Alice unblinds this by dividing out the blinding factor: S = Td/k = Md k (mod n)/k = Md (mod n) • But this is the same as if Bob had just signed M, except Bob was unable to read T e•d = 1 (mod n)
Blind Signatures • It’s a problem signing documents you can’t read • Blind signatures are only used in special situations • Example: • Ask a bank to sign (certify) an electronic coin for $100 • It uses a special signature good only for $100 coins • Blind signatures are the basis of anonymous ecash
eCash (Formerly DigiCash) ALICE SEND UNSIGNED BLINDED COINS TO THE BANK Withdrawal (Minting): WALLET SOFTWARE ALICE BUYS DIGITAL COINS FROM A BANK BANK SIGNS COINS, SENDS THEM BACK. ALICE UNBLINDS THEM BOB VERIFIES COINS NOT SPENT ALICE PAYS BOB Spending: BOB DEPOSITS CINDY VERIFIES COINS NOT SPENT ALICE TRANSFERS COINS TO CINDY PersonalTransfer: CINDY GETS COINS BACK
Minting eCash • Alice requests coins from the bank where she has an account • Alice sends the bank{ { blinded coins, denominations }SigAlice }PKBank • Bank knows they came from Alice and have not been altered (digital signature) • The message is secret (only Bank can decode it) • Bank knows Alice’s account number • Bank deducts the total amount from Alice’s account
Minting eCash, cont. • Bank now must produce signed coins for Alice • Each of Alice’s blinded coins has a serial# • Bank’s public key for $5 coins is (e5, m5) (exponent and modulus). Private key is d5. • Alice selects blinding factor r • Alice blinds serial# by multiplying by re5 (mod m5) (serial# re5) (mod m5) • Banks signs the coin with its private d5 key: (serial# re5)d5 (mod m5) = (serial#)d5 r (mod m5) • Alice divides out the blinding factor r. What’s left is (serial#)d5 (mod m5) = { serial# } SKBank5Just as if bank signed serial#. But Bank doesn’t know serial#. e5•d5 = 1 (mod m5)
Spending eCash • Alice orders goods from Bob • Bob’s serves requests coins from Alice’s wallet: payreq = { currency, amount, timestamp, merchant_bankID, merchant_accID, description } • Alice approves the request. Her wallet sends: payment = { payment_info, {coins, H(payment_info)}PKmerchant_bank } payment_info = { Alice’s_bank_ID, amount, currency, ncoins, timestamp, merchant_ID, H(description), H(payer_code) }
Depositing eCash • Bob receives the payment message, forwards it to the bank for deposit by sending deposit = { { payment }SigBob }PKBank • Bank decrypts the message using SKBank. • Bank examines payment info to obtain serial# and verify that the coin has not been spent • Bank credits Bob’s account and sends Bob a deposit receipt: deposit_ack = { deposit_data, amount }SigBank
Proving an eCash Payment • Alice generates payer-code before paying Bob • A hash of the payer_code is included in payment_info • Bob cannot tamper with H(payer_code) since payment_info is encrypted with the bank’s public key • The merchant’s bank records H(payer_code) along with the deposit • If Bob denies being paid, Alice can reveal her payer_code to the bank • Otherwise, Alice is anonymous; Bob is not.
Lost eCash • Ecash can be “lost”. Disk crashes, passwords forgotten, numbers written on paper are lost. • Alice sends a message to the bank that coins have been lost • Banks re-sends Alice her last n batches of blinded coins (n = 16) • If Alice still has the blinding factor, she can unblind • Alice deposits all the coins bank in the bank. (The ones that were spent will be rejected.) • Alice now withdraws new coins
Anonymous Ecash Crime • Kidnapper takes hostage • Ransom demand is a series of blinded coins • Bank signs the coins to pay ransom • Kidnapper tells bank to publish the coins in the newspaper (they’re just strings) • Only the kidnapper can unblind the coins (only he knows the blinding factor) • Kidnapper can now use the coins and is completely anonymous
Offline Double-Spending • Double spending easy to stop in online systems:System maintains record of serial numbers of spent coins. • Suppose Bob can’t check every coin online. How does he know a coin has not been spent before? • Method 1: create a tamperproof dispenser (smart card) that will not dispense a coin more than once. • Problem: replay attack. Just record the bits as they come out. • Method 2: protocol that provably identifies the double-spender but is anonymous for the single-spender.
Chaum Double-Spending Protocol • Is there a way for the single-sender to remain anonymous by the double-spender is revealed? • YES, if the coins are spent by trusted software • Idea: • Each time the coin is spent, insert information about the buyer of the coin • But, the information can be read only if two different pieces of data are received • If the coin is spent only once, no possibility of different data
Chaum Double-Spending Protocol • Alice wants 100 five-dollar coins. • Alice sends 200 five-dollar coins to the bank (twice as many as she needs). For each coin, she • Combines b different random numbers with her account number and the coin serial number (using exclusive-OR ) • Blinds the coin • Bank selects half the coins (100), signs them, gives them back to Alice • Bank asks her for the random numbers for the other 100 coins and uses it to read her account number • Bank feels safe that the blinded coins it signed had her real account number. (It picked the 100 out of 200, not Alice.)
Probability Footnote • If Alice sends 2n coins to the bank but k have the wrong account number, what is the probability it appears among the n coins the bank picks? • The probability that Alice gets away with it is p(0). • For k = 1, p(0) = 1/2 • For n = 100, k = 10, p(0) ~ 8/10000 • For n = 100, k = 100, p(0) ~ 10-59 WAYS TO PICK EXACTLY n OF 2n TOTAL COINS WAYS TO PICK EXACTLY n- j OF 2n-k GOOD COINS WAYS TO PICK EXACTLY j OF k BAD COINS
Chaum Protocol • Alice’s account number is 12, which in hex is 0C = 00001100 • Alice picks serial number 100 and blinding number 5 • She asks the bank for a coin with serial number100 x 5 = 500 • Alice chooses a number b and creates b random numbers for this coin. Say b=6 • Alice’s wallet XORs each random number with her account number:
Chaum Protocol • Bob receives Alice’s coin. He obtains b and picks a random b-bit number, say 111010 • For every bit position in which Bob’s number has a 1, wallet reveals Alice’s random number for that position • For every 0-bit, Bob receives Alice’s account number XOR her random number for that position • Bob’s wallet sends last column to the bank when depositing
Chaum Protocol • Now Alice tries to spend the coin again with Charlie. He finds b=6 and picks random number 010000 • Her wallet probably sends a different set of numbers • Charlie goes through the same procedure as Bob and sends the numbers he receives to the bank when he deposits the coin
Chaum Protocol • The bank refuses to pay Charlie, since the coin was previously deposited by Bob • The bank combines data from Bob and Charlie (or both) using XOR where it has different data from the two sources: • This identifies Alice as the cheater! Neither Bob nor Alice nor the bank could do it alone
Chaum Protocol • If Alice’s random number has b bits, what is the probability she can spend a coin twice without being detected? • Bob and Charlie’s random numbers would have to be identical. If they differ by 1 bit, the bank can identify Alice. • Probability that two b-bit numbers are identical p(b) = 2-bp(1) = 0.5p(10) ~ .001p(20) ~ 1/1,000,000p(30) ~ 1/1,000,000,000p(64) ~ 5 x 10-20p(128) ~ 3 x 10-39 • Chaum protocol does not guarantee detection
Major Ideas • eCash raises great security concerns • eCash provides protection against loss • eCash raises significant legal problems • eCash is difficult to implement with both anonymity and protection against double spending • eCash may not be successful because of stored-value cards and peer-to-peer systems
Q A &