E-Payment - DePaul University
Download
Report
Transcript E-Payment - DePaul University
E-Payment
ECT 582
Robin Burke
Outline
Schedule changes
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
Transaction cost
cost per transaction
Float
cost to adopt the technology
accrual of accumulated interest
Risk
possible financial loss to buyer / seller
Convenience
Complexity
Two-way
does one or both parties need a special account established
in advance?
Respendability
no need for connection to third-party during transaction
Account
peer to peer payment possible
Off-line
number of steps to complete transaction
no intermediate steps between receiving and spending
Portable
not location-dependent
Interoperability
Exchangeable
Transferable
can be subdivided into smaller units
Hardware independent
can be transferred from individual to
individual
Divisible
one type of currency for another
no special hardware required
Monetary value
built-in value
Overhead
Scalability
Delay
transactions / users
how long does the transaction take?
Hardware / software requirements
Examples
Cash
Check
Credit card
Online credit card
Mondex
PayPal
Digital wallet
Framework
Players
Processes
who is involved
what is the protocol
Properties
costs
risks
etc
Cash
Players
buyer / seller (Bob & Susie)
Process
secure document
fixed amount
physical exchange
Cash properties
anonymity
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
Traceable
Non-anonymous
Medium cost
Bob and Susie
10-20¢
Risk to seller if verification not in place
Non-transferable (in theory)
biometric authentication
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 email address
Susie can access her funds by creating a
PayPal account linked to her email address
Characteristics
Low transaction cost
Re-spendable
On-line only
Viral
recipient must get an account to get paid
Traceable, non-anonymous
must be "backed"
by a credit card or bank account
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
Authorization
Bob presents card or
Bob presents card number plus other information
Susie contacts SK with card info
SK contacts T
T contacts BC
BC can accept, deny, etc.
Capture
Transaction is committed
•
Authorization steps happen again with capture flag
card balance debited
Settlement
goods accepted
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. CNP
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
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
Similar to private key token for PKI BUT
key used to authenticate as "real" Mondex
device
key used to encrypt memory contents
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
When spending
bank can verify just like $ amount
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
Digital wallet
The cure-all that wasn't
eWallet
Java Wallet
discontinued
MS Passport
out of business
no longer includes credit card info
W3C digital wallet initiative
discontinued
Why?
information not portable
information too portable
single machine
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
Homework #5
Protocol design
Tax uploading problem
Next week
Internet security
Firewalls