Software Infrastructure
for Electronic Commerce
Electronic Payment
Systems
Professor Fred B. Schneider
Dept. of Computer Science
Cornell University
Goals


Learn about properties of payment systems.
Exposure to extant payment systems:
– What services do they provide?
– What risks do they introduce?

Understand forces that shape when/whether a
payment system will enjoy widespread adoption.
1
E-Payment Potential

For existing business
Reduce order-taking costs with automation.
Project modern and competitive image.
by substituting network for:
Catalog and/or
Ordering.

For new business:
– Exploit immediacy of the networked communication to convert
to auction-based commerce.
– Tailor the “store” to individual customers:
Monitoring customer activity by web server allows “knowing your
customer” (as done today with affinity cards).
Increased need for data mining.
2
E-Payment Risks to Customer


Merchant could misuse information provided for
transactions by customer.
Merchant could penetrate customer’s site, glean
information about the customer, and misuse
that.
E.g., Merchant offers higher prices based on customer’s
past behavior (at this or other sites).
3
E-Payment Risks to Merchant



Customer could really be a competitor attempting
to learn prices or strategy.
Customer could be an imposter, and bill will not
be paid.
Customer could be a hacker:
–
–
–
–
changes what will get ordered by bona fide customers.
changes what prices are charged.
changes what is available.
steals customer contact information.
4
Security Issues to Address
Transaction security: Implement privacy
and integrity of sale or other activity.
Digital payment: Implement privacy,
integrity, provenance of an agreement to
transfer or debit funds.
5
Transaction Security:
Some Political Realities

Technology providers have incentive to deploy
new, non-interoperating, systems.
Constantly shifting alliances.
“Big players” sought to endorse various “standards”.
Standards bodies (e.g. IETF) are unable to exert leadership.

Today: Many competing standards.
Recommendation: Pick a technology that is widely
deployed; otherwise customer base is constrained.
“I love standards. There are so many good ones to choose from.”
6
Transaction Security:
Technical Approaches
Problems to solve:
 Confidentiality,
 Integrity, and
 Authentication.
App
Net
Two general solution approaches:
Add support for encryption
1. Augment lower levels of system with support for
encryption.
2. Include support for encryption in applications.
7
Transaction Security:
Consequences of Approaches

Augmenting lower levels (e.g., network layer):
– Restricted interoperability
– Costs (e.g., encryption) borne by all users, whether security
functionality is needed..
+ Can easily support legacy applications and COTS.
+ Transparent to applications and users.

Modifying the application:
– Often adds extra set-up phase and other messages for crypto-key
exchange, increasing delay.
+ Clear trust boundaries and smaller TCB.
+ Can be deployed through web browser (helper apps).
Recommendation:
Today… web browser helper app
Tomorrow… expect lower level support.
8
Transaction Security:
Examples

Augmenting lower levels:
– IPv6 (“IPSEC”)… Slowly being deployed.

Modifying the application:
– S-HTTP (rip)
– Secure Socket Layer (SSL)
Netscape strategy: Promote e-consumer fear, which pressures
e-merchants to use Netscape web servers supporting
Netscape’s SSL.
SSL 3.0 is basis for IETF Transport Layer Security (TLS).
9
Transaction Security:
Example: SSL

Functionality:
– Secrecy of in-transit messages.
– Integrity of in-transit messages (thru MAC)
– 2-way authentication


Separate algorithms and keys for encryption, data
integrity, authentication due to U.S. export restrictions.
Actual Operation:
1. Opening handshake
2. Application dialog
3. Closing handshake
App
App
SSL
SSL
TCP/IP
TCP/IP
To use SSL w browser
http://www.company.com/…  https://www.company.com/…
10
Digital Payment Systems
Digital payment system: Allows transfer of
value without transfer of physical objects.
Payment by bits rather than atoms.
00101 00 1 1110
11
Historical Perspective

1118 – 1307 AD: Knights Templar support pilgrimage trade:
Deposit funds with local Templar and receive coded chit.
Templar representatives along the journey would make
expenditures, re-code the chit, and return to owner.
At journey’s end, chit was presented to local Templar and
account would be settled.



1928: Farrington Manufacturing Company (Boston)
introduces “charge plate” embossed with customer name
and address.
1949: Alfred Bloomingdale, Fran McNamara, & Ralph Snyder
conceive of “universal” charge card (“Diners Club”) for
entertaining.
1958: American Express & Carte Blanche created.
12
Credit Card Transactions
Consumer: C
Merchant: M
Consumer’s Bank: CB
Merchant’s Bank: MB
Making a Purchase:
1.
2.
3.
4.
5.
6.
C  M: Order and Credit card.
M  MB: Request authorization.
MB  CB: Request for authorization.
CB  MB: Approval (Funds may be put on hold).
MB  M: Approval.
M  C: Fill order and ship.
13
Credit Card Transactions (con’t)
Consumer: C
Merchant: M
Consumer’s Bank: CB
Merchant’s Bank: MB
Merchant Receives Payment:
1.
M  MB: Batch of charge slips
2.
MB  CB: Request for $$.
3.
CB  Clearinghouse: Debit consumer;
credit settlement acnt.
4.
Clearinghouse  MB: Debit settlement acnt;
credit merchant acnt.
14
Credit Card Limitations
Risk: [1997] Consumers liable only for first
$50.00 of fraudulent credit card transaction.
Cost: Per transaction: $0.25 - 0.75.
Customer reluctance:
– Some consumers are hesitant to give out name,
address, or account number.
– Not everyone has a credit card.
15
E-Payment System Characteristics

Who assumes the risk?
Buyer? Merchant? Intermediary?

Who is known to whom:
– Anonymous: merchant or bank cannot learn identity of
the consumer making a purchase.
– Private: merchant does not learn the identity of
consumer (but intermediary may).
– Identifying: Merchant and customer know each other.

What is per-transaction cost?
Might pay more to reduce risks (if greater value is at stake).
16
E-Payment Systems
Example: First Virtual
The first payment system widely deployed on the
Internet…
Goal: Lower barriers to web commerce using
as little additional infrastructure beyond the
internet as possible.
– Anticipates new breed of merchants that wouldn’t
meet credit card company standards.
– Shifts burden of trust to buyer, making it easier to
become merchant.
17
E-Payment Systems
First Virtual Commerce Model

With ordinary credit cards: Risk associated with
time gap between
– merchant paid
-and– buyer pays credit card bill.

First Virtual commerce model:
Delay payment to merchant for 90 days.
Allows buyer-merchant dispute period to expire before
merchant is paid.
18
E-Payment Systems
Example: DigiCash
Goal: Implemented electronic cash for anonymous
e-payment. Was a market failure.
Digital coin is the unit of currency:
– Has unique serial-number.
– Created by buyer or bank.
– Stored on buyer’s local disk or bank’s local disk
Forgery + anonymity is a hard problem!!!!
… Hard to copy a bank note; anyone can copy a bit
pattern.
19
E-Payment Systems
DigiCash Coin Minting

Payer and bank cooperate to mint coins:
– Many denominations possible.
– Bank does not learn serial number of new coin (until
after that coin is spent). But bank signs coin.

Bank has PUBLIC/private key pair for each
denomination. They are inverses.
– E.g. WASH/wash, LINC/linc, JEFF/jeff, …

Coins have self-checking serial numbers.
– E.g. Number in 2 halves: 12345 54321
20
E-Payment Systems
DigiCash Coin Minting Protocol
Payer:
Invent new coin self-checking number n;
Invent and store random number r;
Payer  Bank: B = n * (rWASH)
Bank:
Debit payors account by $1.00;
B’ = Bwash
= (n * rWASH)wash
= nwash * rWASH*wash
= nwash * r1
[Bank doesn’t learn n.]
Bank  Payer : B’
Payer: Coin is
B’/r (= nwash )
[n signed by bank is coin]
21
E-Payment Systems
DigiCash Coin Checking Protocol


Bank stores serial numbers for coins that have
been spent.
Payer receiving coin B’ (=nwash) checks it:
– Is B’ correctly signed? Use public key WASH to check.
– Does (B’)WASH have correct form: 12345 54321?
– Communicate with bank:
Has n already been spent?
Save n for future double-spending checks.
Return a fresh coin (new serial number) if payer doesn’t want
to spend B’.
22
E-Payment Systems
Example: Millicent
Goal: Ultra-low cost transactions.
Approach: Prepaid, verifiable cash equivalents in
small denominations. Clearance and reconciliation
properties relaxed to lower costs.
– Based on script (like prepaid phone card, transit pass).
Each merchant issues merchant-specific script.
Buyers get script from broker.
Broker obtains script — in bulk — from merchant.
Uses hash rather than encryption to prevent forged script.
23
E-Payment Systems
SET (Secure Electronic Transactions)

Collaboration between VISA, Mastercard,
American Express
– Uses many keys
2 x customer, 2 x seller, 2 x intermediary handler
– Assumes full PKI, including revocation.
– Complex protocols. May never be deployed
(despite years in the making).
24
Infrastructure Dependence
Electronic payment systems and internet
commerce introduce dependence on
infrastructure:
– Database becomes accessible to the world via
the Internet.
– Web server open to Trojan Horses and other
attacks.
– Denial of service attacks.
– Communications outages.
25
For additional reading …


Web Security Sourcebook. Aviel D. Rubin, Daniel
Greer, Marcus J. Ranum. J. Wiley, New York,
1997.
Web Security and Commerce. Simson Garfinkel
with Gene Spafford, O’Reilly & Associates, Inc.
Cambridge, 1997.
26