Lesson 18
Electronic Payment
Systems
Overview
• Data Transaction Systems
• Securing the Transaction
• Real World Examples
Data Transaction Systems
• Stored Account Systems
– Modeled after existing electronic payment
systems such as credit/debit card transactions
– New way of shifting funds electronically over
the internet (Paving Cow Paths)
• Stored Value Payment Systems
– Use bearer certificates much like hard cash
– Bearer certificates reside within PCs or smart
cards
Stored Account Systems
• Uses existing infrastructure for transactions
• Actual monetary value never leaves bank
• Accounting in the future through clearing
houses and settlement systems
• Hallmarks are:
– High accountability
– Traceability
Stored Account Systems(2)
• Payment systems have defined their own
secure technologies
• 1995: $13 trillion, in 3 billion transactions by
4 clearing houses
• Fed Reserve Fedwire transfers $1 trillion/day
• Fraud exists now but risk management
models in place
Stored Account Systems(3)
• Protocols for supporting credit card types of
transactions have been defined and
implemented for E-commerce
– First Virtual’s Internet Payment System
– Cyber Cash’s Secure Internet Payment System
– Secure Electronic Transaction (SET)
• Many new technologies emerge daily
• Security and convenience will rule the
market place--it’s a balancing act
Stored Value Payment
Systems(SVPS)
• Attempts to replace cash with electronic
equivalent….E-Cash
– No More Cow Paths
• Instantaneous transfer of value, does not
require bank approval
• Security stakes are much higher than
stored account systems
• Attributes: absence of control and auditing
SVPS(2)
• Possible to counterfeit E-Cash
• Typically used in small-value
transaction
– Small value transaction market = $8
trillion
• Lack of privacy bothers some
• Finding new cow paths not easy
SVPS(3)
• Author says: “most exciting, innovative,
and risk forms of accepting payment”
• Replaces currency with digital equivalent
• Value placed directly on hardware tokens
such as PCs or Smart Cards
• Goal: have the advantages of hard
currency systems over an electronic
medium
Attributes of Hard Currency
ADVANTAGES
• Not easily traceable
• Instantaneous payment
• No bank interference
•
•
•
•
•
DISADVANTAGES
Costly to transport
Costly to protect
Easily lost or stolen
Can be forged
Parties must be in
close proximity to
exchange
SVPS Pros/Cons
Pros
• Instantaneous (no
approval needed)
• Potentially Anonymous
(traceability hard)
• Supports low-value
payment
Cons
• Secret key from one can
be used for many
• Secret key extraction
makes counterfeit money
indistinguishable for ECash
• SVPS must strike balance
between privacy and
tracking illicit activity
How E-Cash Works
• E-Cash stored in an electronic device,
called a hardware token
– Secure processor and non-volatile memory
• Consumers load money into token
– Token’s value counter is incremented
– Or Value loaded as register-based cash &
electronic coins
• Payment can be made on-line or off-line
E-Cash Online Payment
• Purchaser deals directly with seller’s
hardware token device
• Bank must be an intermediary
– Allows for traceability
• The H/W devices must be interoperable
Off-line Payment
• Buyer’s H/W token interfaces with seller’s device
– IR, dial-up modem, or the Internet
• Sellers device increases by transaction amount
• Buyers’s device decreases by transaction amount
• Safeguards needed to prevent “counter” malfunction
• E-Cash ultimately must be sold back to issuing bank
E-Cash Representation
• A value stored in a counter of a H/W
token (aka register-based)
• From of cryptographic tokens called
electronic coins
Register Based
Basic unit = 1 cent
Token cntr = 10000
Token value = $100.00
E-Coin System
“A Purse”
Cents = count + digital
signature
$ = count + digital signature
5$ = count + digital signature
Token value is sum of all
Securing E-Cash
• Security concerns for SV PS>> SAPS
– Main reason: lack of traceability  fraud
potential
• Main concern: potential to illegally add
value to the H/W token
• Physical Attacks on H/W token
• Protocol based attack that mimics a
paying device
Physical Attacks
Physical
• An attempt to alter non-volatile memory
– Device needs to be shielded so its tamper
resistant
– or device needs to be tamper evident
Protocol Attacks
Protocol
• Device counter illegally incremented by
“fake” paying device
– Secure authentication needed to ensure
“fakes” don’t work
– Best way is for both devices to share a
symmetric cryptographic key
– All devices do not use a master key
– Secret key = master key + device unique ID
Protocol Attacks(2)
• Key must be resistant to replay attacks
– Wiretap captures key and “replays” the
session
– Challenge/Response systems can thwart
replay attacks
• Gives motive for the token bearer to
recover secret key
– Greed is a powerful sin
Alternative Approach
• PKE is an alternate
– Compromise of public key will not allow
reconstruction of secret key
– Response to challenge is digital signature
• Disadvantage is that token cannot
contain public keys for all paying devices
• Advantage is ability to prove that
accumulated value is legit
– Digital signatures from paying devices
authorize the accumulated values
Securing the Transaction
WEB Protocols
• SSL: provides secure channel between
Web clients and Web servers
– Layered approach--remember protocol
stack
– Secures channel by providing end-to-end
encryption of the data
– Prevents “easy” packet sniffing
• S-HTTP: application level protocol
Protocol and Security: SSL
NOT SECURE
SECURE
HTTP
SMTP FTP
HTTP
SSL
TCP
TCP
IP
IP
Protocol and Security: SHTTP
NOT SECURE
HTTP
SECURE
HTTP
Security
TCP
TCP
IP
IP
Securing the Transaction(2)
• Certificate Authority (CA)
– Endorses identity of the Web server (or
user)
– No assurance of the quality of Web
content
– Users implicitly trust any sites that come
loaded in their browser
The Little Yellow Lock = Warm Fuzzy
Secure Payment Protocols (SPP)
vs WEB Protocols
• SPPs provide a method to assure a
merchants payment
• SPPs provide consumers assurance of
credit card confidentiality
• Web protocols (like SSL) leave payment
details up to the merchant
• Web protocols do not assure merchant
will safeguard credit card number
Real World Examples
• First Virtual
• Cybercash
• Secure Electronic
Transactions (SET)
• Others
First Virtual(FV)
• WWW.fv.com--circa 1994
• Does not use cryptography or secure
communications
• Based on exchange of email messages and
customer honesty
• Protocol I simple
• 1996: 180,000 buyers, 2650 merchants
FV IN ACTION(1)
First Value
1. Establish acct-$2
with VISA/MC
0. FV Merchant Setup
6. VPIN, Transaction
via email
2. Virtual PIN
3. Request Product
4. Send VPIN?
Customer
5. VPIN SENT
FV Merchant
FV IN ACTION(2)
SEVERAL DAYS
LATER
First Value
3. MC/VISA Charge
1. Transaction
Confirmation?
3. Or Return
product
2. Yes, No, Fraud
Customer
FV Merchant
CyberCash
• Cybercash is a downloadable applications
software
• Consumers must generate public/private key
pair based on RSA encryption technology
• Merchants must also install CyberCash
Library
• Software free to stimulate acceptance
• Future: could be integrated into browsers
• More to come…CyberCoin, and E-Cash Soln
CyberCash(2)
• Uses Cryptography to protect transaction
data during a purchase (does not use SSL)
• Provides a secure protocol for credit card
purchases over the internet
• Uses existing back-end credit card
infrastructure for settling payment
• Payment details of credit card transaction
are specified and implemented in the
protocol
CyberCash(3)
Merchant’s Perspective
• There is no separate back-office system for
batch processing card transaction
• Payment assured for each transaction
before product sold
– Much like point-of-sale(POS) credit card
transactions in physical stores
CyberCash(4)
• Credit card number is protected--even
from merchants
• Card number encrypted with CyberCash
public key
• Only consumer, cybercahs and bank sees
the credit card number
CYBERCASH IN ACTION
Customer
2. Go E-Shopping, Request Product Merchant
3. Invoice Sent
5. Send Payment Info
1. Register
Credit Card
4a. Select Cybercash Pay
button in browser
4b. Select Credit card from
6a. Strip Order
Form
6b. Digitally Sign
Info
E-wallet
4c. Encrypt payment
CYBERCASH
info with CyberCash Public
Key
4d. Digitally Sign Payment
BANK
info
BANK
CYBERCASH IN ACTION
Customer
2. Go E-Shopping, Request Product Merchant
3. Invoice Sent
5. Send Payment Info
7. Transmit Payment info
8. Decrypt payment
info & verify signatures
Bank EDI
CYBERCASH
9. Brokering
20 SECONDS TOTAL
10. Approval/Deny
9. Brokering
BANK
Card Holder BANK
Secure Electronic Transaction (SET)
• SET is an emerging open standard for secure
credit card payments over the internet
• Created by Mastercard and Visa
• Specifies the mechanism for securely
processing internet-based credit card orders
• Does not specify the implementation
• Does not specify the shopping or order
process for ordering goods, payment
selection, and the platform or security
procedures
SET Security Assurances
• Confidentiality -- secures payment info
• Data integrity -- uses digital signatures
• Client Authentication -- uses digital
certificates: identity plus public key
• Merchant authentication -- uses digital
certificate
SET Steps
1. The customer opens an account with a
certificate authority.
2. An issuing authority, like a bank, issues a
digital certificate authenticating a customer.
3. Other third-party merchants also receive
their digital certificate when they open their
transaction accounts.
4. The customer places an order.
SET Steps
5. Customer verifies the merchant’s digital
certificate .
6. Customer sends encrypted purchase details.
7. When the merchant receives the order, the
customer’s own digital certificate is checked
for authenticity as well.
SET Steps
8. The merchant then returns its own certificate, order
details, customer payment information, and the
bank’s digital certificate back to the bank to be used
to authenticate the transaction.
9. The bank will then verify the merchant certificate
and order information.
10. The bank will digitally sign and return an
authorization back to the merchant.
11. When these transactions are finished, the order is
completed.
SET IN ACTION
4. Place Order
5. Merchant Certificate Sent
Customer
Merchant
6. Send encrypted purchase details w/ Certificate
2. Buyer Opens Acct
1. Merchant receives
Digital Certificate
3. Buyer receives
Digital Certificate
BANK
7. Sends order to Bank w/
customer payment info &
digital certificate
SET IN ACTION
4. Place Order
5. Merchant Certificate Sent
Buyer
Merchant
6. Send encrypted purchase details w/ Certificate
2. Buyer Opens Acct
9. Bank digitally
signs & sends auth
to merchant
3. Buyer receives
Digital Certificate
7. Sends order to Bank w/
customer payment info &
digital certificate
10. ORDER COMPLETE
BANK
8. Bank verifies merchant
certificate and order info
SET Summary
•
•
•
•
Large industry backing
Supports credit card transactions on-line
Does not support debit card payments
Does not address stored-value payment
solutions
• Does not use SSL, but it could
• Implementations:
– Cybercash
– RSA Data Security’s: S/PAY
Other Examples
• DigiCash’s e-cash: stored-value
cryptographic coin system
• CyberCoin--CyberCash’s payment
system for on-line commerce
– Designed for small-value payments
• Smart Cards
– Conditional Access for Europe (CAFÉ)
– Mondex
– Visa Cash
Summary
• Data Transaction Systems
– Stored Account Systems
– Stored Value Payment Systems
• Securing the Transaction
– SSL, S-HTTP and Secure Payment Protocols (SPP)
• Real World Examples
– FV, CyberCash, SET, E-Cash, and others