eCommerce Technology Lecture 13 Electronic Cash

Slides:



Advertisements
Similar presentations
Digital Cash Mehdi Bazargan Fall 2004.
Advertisements

David Evans CS588: Cryptography University of Virginia Computer Science Lecture 18: Money
Recoverable and Untraceable E-Cash Dr. Joseph K. Liu The Chinese University of HongKong.
Understanding Networked Applications: A First Course Chapter 14 by David G. Messerschmitt.
Lect. 18: Cryptographic Protocols. 2 1.Cryptographic Protocols 2.Special Signatures 3.Secret Sharing and Threshold Cryptography 4.Zero-knowledge Proofs.
Digital Cash Present By Kevin, Hiren, Amit, Kai. What is Digital Cash?  A payment message bearing a digital signature which functions as a medium of.
ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 11 Electronic Cash.
Slide 1 Vitaly Shmatikov CS 378 Digital Cash. slide 2 Digital Cash: Properties uDigital “payment message” with properties of cash uUnforgeable Users cannot.
Presentation by Team 4.  What Is It?—Tim Johnson  How Does it Work—Javier Navarro  Different Kinds of Cryptocurrency—Idong  Challenges—Mark Weeks.
Payment Systems 1. Electronic Payment Schemes Schemes for electronic payment are multi-party protocols Payment instrument modeled by electronic coin that.
Department of Information Engineering1 Major Concerns in Electronic Commerce Authentication –there must be proof of identity of the parties in an electronic.
Introduction to Modern Cryptography, Lecture 13 Money Related Issues ($$$) and Odds and Ends.
ELECTRONIC PAYMENT SYSTEMSFALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 6 Epayment Security II.
ECOMMERCE TECHNOLOGY SUMMER 2002 COPYRIGHT © 2002 MICHAEL I. SHAMOS Cryptographic Security.
ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 11 Electronic Cash.
ECOMMERCE TECHNOLOGY FALL 2003 COPYRIGHT © 2003 MICHAEL I. SHAMOS Cryptography.
1 Applications of Computers Lecture-3 2 E-Commerce 4 Almost all major companies have their homes on the web, mainly for advertising 4 Companies were.
Digital Cash Damodar Nagapuram. Overview ► Monetary Freedom ► Digital Cash and its importance ► Achieving Digital Cash ► Disadvantages with digital cash.
ITIS 6200/8200. time-stamping services Difficult to verify the creation date and accurate contents of a digital file Required properties of time-stamping.
Electronic Voting Schemes and Other stuff. Requirements Only eligible voters can vote (once only) No one can tell how voter voted Publish who voted (?)
How cryptography is used to secure web services Josh Benaloh Cryptographer Microsoft Research.
ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 9: Micropayments II.
ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 6 Epayment Security II.
Module 8 – Anonymous Digital Cash Blind Signatures DigiCash coins.
ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS eCommerce Technology Lecture 9 Micropayments I.
Electronic Payment Systems. Transaction reconciliation –Cash or check.
Financial Transactions on Internet Financial transactions require the cooperation of more than two parties. Transaction must be very low cost so that small.
E-Money / Digital Cash Lin Huang. Money / Digital Cash What is Money –Coins, Bill – can’t exist on two places at one time –Bearer bonds: immediate cashable.
ELECTRONIC CASH FALL 2000 COPYRIGHT © 2000 MICHAEL I. SHAMOS CPS 214 Bank Clearing and Settlement Quantum Key Exchange Electronic Cash.
Electronic Payment Systems In any commercial transaction payment is an integral part for goods supplied. Four types of payments may be made in e-commerce.
J. Wang. Computer Network Security Theory and Practice. Springer 2008 Chapter 4 Data Authentication Part II.
Digital Cash By Gaurav Shetty. Agenda Introduction. Introduction. Working. Working. Desired Properties. Desired Properties. Protocols for Digital Cash.
MIS 3090 IT for Financial Services Digital Cash September 4, 2015.
Chris Olston, cs294-7, Spring Atomicity in Electronic Commerce J. D. Tygar -- UCB presented by Chris Olston.
Bitcoin (what, why and how?)
Electronic Payment Systems. How do we make an electronic payment? Credit and debit cards Smart cards Electronic cash (digital cash) Electronic wallets.
_______________________________________________________________________________________________________________ E-Commerce: Fundamentals and Applications1.
Digital Cash. p2. OUTLINE  Properties  Scheme  Initialization  Creating a Coin  Spending the Coin  Depositing the Coin  Fraud Control  Anonymity.
Privacy Enhancing Technologies Spring What is Privacy? “The right to be let alone” Confidentiality Anonymity Access Control Most privacy technologies.
Software Security Seminar - 1 Chapter 5. Advanced Protocols 조미성 Applied Cryptography.
Chapter 6:Esoteric Protocols Dulal C Kar. Secure Elections Ideal voting protocol has at least following six properties 1.Only authorized voters can vote.
E-Payment ECT 582 Robin Burke. Outline Characteristics Select protocols.
Chapter 9 Checking Accounts.
2/16/001 E-commerce Systems Electronic Payment Systems.
Security Digital Cash Onno W. Purbo
31.1 Chapter 31 Network Security Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Electronic Cash R. Newman. Topics Defining anonymity Need for anonymity Defining privacy Threats to anonymity and privacy Mechanisms to provide anonymity.
Electronic Payment Systems Presented by Rufus Knight Veronica Ogle Chris Sullivan As eCommerce grows, so does our need to understand current methods of.
David Evans CS588: Security and Privacy University of Virginia Computer Science Lecture 14: Digital Cash, Randomness.
BZUPAGES.COM E-cash Payment System A company, DigiCash, has pioneered the use of electronic cash or e-cash. Anonymity of the buyer is the key feature of.
多媒體網路安全實驗室 Private Information Retrieval Scheme Combined with E- Payment in Querying Valuable Information Date: Reporter: Chien-Wen Huang 出處:
A Secure Online Card Payment Protocol VIJAY CHOUDHARY M.Tech(IS), DTU.
1 E-cash Model Ecash Bank Client Wallet Merchant Software stores coins makes payments accepts payments Goods, Receipt Pay coins sells items accepts payments.
CS580 Internet Security Protocols Huiping Guo Department of Computer Science California State University, Los Angeles 6. Blind Signature.
CS480 Cryptography and Information Security Huiping Guo Department of Computer Science California State University, Los Angeles 14. Digital signature.
PAYMENT GATEWAY Presented by SHUJA ASHRAF SHAH ENROLL: 4471
Computer Communication & Networks
Onno W. Purbo Security Digital Cash Onno W. Purbo
Chapter 9 Security 9.1 The security environment
BY GAWARE S.R. DEPT.OF COMP.SCI
Trezor Support Phone Number For You!! Round The Clock
Lecture 12: Randomness and Cash
Secure Electronic Transaction (SET) University of Windsor
Cash Control and Banking Activities
Internet Payment and DigiCash
Chapter 13 Digital Signature
Electronic Payment Security Technologies
Chapter 8 roadmap 8.1 What is network security?
Presentation transcript:

eCommerce Technology 20-763 Lecture 13 Electronic Cash 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

No existing system solves all these problems Electronic Cash Electronic cash is 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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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. 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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! 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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. 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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) 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 Personal Transfer: CINDY GETS COINS BACK 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 r e5 (mod m5) (serial# r e5) (mod m5) Banks signs the coin with its private d5 key: (serial# r e5)d5 (mod m5) = (serial#)d5 r (mod m5) Alice divides out the blinding factor r. What’s left is (serial#)d5 (mod m5) = { serial# } SKBank5 Just as if bank signed serial#. But Bank doesn’t know serial#. e5 • d5 = 1 (mod m5) 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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) } 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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. 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

Anonymous Ecash  Crime Kidnapper takes hostage Ransom demand is a series of blinded coins Banks 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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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. 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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.) 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 j OF k BAD COINS WAYS TO PICK EXACTLY n- j OF 2n- k GOOD COINS 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 number 100 x 5 = 500 Alice chooses a number b and creates b random numbers for this coin. Say b=6 Alice XORs each random number with her account number: 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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, he receives 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 sends the last column to the bank when depositing the coin 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

Chaum Protocol Now Alice tries to spend the coin again with Charlie. He finds b=6 and picks random number 010000 Charlie goes through the same procedure as Bob and sends the numbers he receives to the bank when he deposits the coin 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

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 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

Chaum Protocol Chaum protocol does not guarantee detection 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 -b p(1) = 0.5 p(10) ~ .001 p(20) ~ 1/1,000,000 p(30) ~ 1/1,000,000,000 p(64) ~ 5 x 10 -20 p(128) ~ 3 x 10 -39 Chaum protocol does not guarantee detection 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS 52

Q A & 20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS