E-Payment ECT 582 Robin Burke

Outline Characteristics Select protocols

Characteristics of payment systems Security / Privacy Convenience Cost Overhead Interoperability

Security / Privacy Anonymous seller or buyer authentication required? Non-repudiation secure receipt generated? Security against theft? against forgery? against double-spending? Privacy properties of transaction hidden from involved parties Fail-safe is money lost / created in system failure?

Cost Fixed cost cost to adopt the technology Transaction cost cost per transaction Float accrual of accumulated interest Risk possible financial loss to buyer / seller

Convenience Complexity number of steps to complete transaction Two-way peer to peer payment possible Off-line no need for connection to third-party during transaction Account does one or both parties need a special account established in advance? Respendability no intermediate steps between receiving and spending Portable not location-dependent

Interoperability Exchangeable one type of currency for another Transferable can be transferred from individual to individual Divisible can be subdivided into smaller units Hardware independent no special hardware required Monetary value built-in value

Overhead Scalability transactions / users Delay how long does the transaction take? Hardware / software requirements

Examples Cash Check Credit card Online credit card Mondex PayPal Digital wallet

Framework Players who is involved Processes what is the protocol Properties costs risks etc

Cash Players buyer / seller (Bob & Susie) Process secure document fixed amount physical exchange

Cash properties anonymity divisibility exchangable low cost repudiable, without receipt step low tech monetary untraceable

Check Players Bob, Susie Bob's bank BK, Susie's bank SK Verification service V Process physical exchange secure document with biometric ID Susie may verify with V before accepting Susie deposits with SK SK settles with BK via ACH Bob's account at BK debited

Check properties Accounts required Bob and Susie Traceable Non-anonymous Medium cost 10-20¢ Risk to seller if verification not in place Non-transferable (in theory) biometric authentication

Credit card Players Bob, Susie, SK (acquirer) Card issuer BC Transaction processor T Setup Susie must have card processing account SK leases POS hardware and network access Bob must have credit card

Credit card cont'd Presentation Bob presents card or Bob presents card number plus other information Authorization Susie contacts SK with card info SK contacts T T contacts BC BC can accept, deny, etc. Capture Transaction is committed goods accepted Authorization steps happen again with capture flag card balance debited Settlement BC transfers money to SK Billing BC sends Bob a monthly bill Bob pays BC

Credit card cont'd non-anonymous non-transferable security weak esp. NSP designed to thwart simple theft off-line = low security not interoperable low cost / low risk for buyer BC absorbs fraud risk

Online credit card same as before except weak buyer authentication physical card never present physical signature never present security reduced from biometric to data weak seller authentication major fraud opportunity SSL protects only passive attacks on IP traffic

SET Same players as credit card Central idea Susie only needs to know that she will get paid Bob's card number not essential BC only needs to know enough to validate the transaction Segment the transaction Part for Susie Part for BC

SET cont'd

Process Susie and BC have public keys Bob encrypts and signs an order O to Susie Bob encrypts and signs payment information P to BC P is sent through the acquirer to BC BC decrypts and validates the transaction Sends Susie verification and transaction id Susie presents transaction id to acquirer for settlement

SET cont'd Properties authentication of seller non-disclosure of credit card # non-disclosure of order details enhanced privacy hardware / software requirement electronic wallet Slow adoption of SET requires PKI (hierarchical) requires client-side software incompatible wallet implementations

Mondex Players Bob, Susie Setup Bob and Susie both have Mondex smart cards Bob has downloaded cash tokens to his Mondex card Bob or Susie has a Mondex terminal money exchange device Process connect cards to terminal enter respective PINs cards authenticate each other's certificates Susie's card generates signed purchase request Bob's card acknowledges request and deletes stored tokens Susie's card adds tokens

Mondex cont'd Characteristics limited maximum storage reduces danger of money laundering some buyer risk stolen card is lost cash respendable two-way convenient dependent on secure hardware risky assumption

Secure hardware Private key stored in device key used to authenticate as "real" Mondex device key used to encrypt memory contents Similar to private key token for PKI BUT owner has incentive to break in How to build packaging internal consistency checks "reset on fault"

Attacks against secure hardware Problem physics of device cannot be hidden Attackers can etch new circuitry remove deletion step alter encryption algorithm monitor encryption to capture secret key power consumption timing bus probe

Should we worry? Question where does "expected payoff" > "investment to break" Answer if Mondex becomes widespread chip tampering = printing money Attackers Class I – capable outsider Class II – knowledgeable insider Class III – determined organization

eCash Players Bob, Susie Setup Bob and Susie have eCash accounts and eCash software or smart card Bob loads secure "coins" to wallet a coin = a $$ amount, an id and a digital signature Process Bob transfers coins to Susie Susie deposits in account

Characteristics Anonymous Two-way Non-traceable Respendable Forgery cryptographic problem

Anonymity Coin only has bank's identifier Bank doesn't know who originally withdrew it whose hands it has passed through Problem double spending bank can detect but is Susie or Bob at fault withdrawal when coins are given to Bob, ids could be recorded

Blind signature Problem sign a document without looking at it Solution multiple message by a factor M*F sign M*F creating M*F + S factor out F leaving M + S/F for certain algorithms S/F is the correct signature for M Bob can create a message = "$1" blind it have bank sign it deduct $1 from Bob's account create coin

Cut and choose Bob could also create a message = "$100" blind it tell the bank it says "$1" have bank sign it Solution Bob creates n messages Bank examines n-1 at random if they all say "$1" then the bank signs we pick n to be as large as necessary for security may depend on size of transaction

Double spending What if Bob spends the same coins twice? What if Susie deposits the same coins twice? Bank can detect same id deposited twice can't distinguish

Conditional anonymity Bob encrypts self-identifying information in the coin bank can verify just like $ amount When spending Bob discloses 50% of the key used to decrypt personal info if he spends twice, his identity becomes known to the bank A similar device can be used to protect against double deposits

Double spending

eCash viability Untraceability + anonymity + virtuality many opportunities for crime governments hate it DigiCash founder Chaum went bankrupt some patents will expire soon

PayPal Players Bob, Susie, PayPal Setup Bob needs a PayPal account linked to a bank account or credit card Process Bob uses the PayPal application to send money using Susie's address Susie can access her funds by creating a PayPal account linked to her address

Characteristics Low transaction cost Respendable On-line only Viral recipient must get an account to get paid Traceable, non-anonymous

Digital wallet The cure-all that wasn't eWallet out of business Java Wallet discontinued MS Passport no longer includes credit card info W3C digital wallet initiative discontinued

Why? information not portable single machine information too portable third party insufficient trust in client software

Conclusion Very few e-payment success stories Credit cards approximately 1.8 billion in fraud on-line in 2002 still the dominant mechanism Reasons convenience already in use low buyer risk