Software Infrastructurefor Electronic Commerce

Electronic Payment Systems

Professor Fred B. SchneiderDept. of Computer Science

Cornell University

2

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.

3

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.

4

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).

5

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.

6

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.

7

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.”

8

Transaction Security:

Technical Approaches

Problems to solve: Confidentiality, Integrity, and Authentication.

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.

App

Net

9

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.

10

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).

11

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 handshake2. Application dialog3. Closing handshake

To use SSL w browserhttp://www.company.com/… https://www.company.com/…

SSL

TCP/IP

App

SSLSSL

TCP/IP

App

SSL

12

Digital Payment Systems

Digital payment system: Allows transfer of value without transfer of physical objects.

Payment by bits rather than atoms.

110101101010110101110100 101 1111 01

00101 00 1 1110

13

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.

14

Credit Card Transactions

Consumer: C Consumer’s Bank: CBMerchant: M Merchant’s Bank: MB

Making a Purchase:1. C M: Order and Credit card.2. M MB: Request authorization.3. MB CB: Request for authorization.4. CB MB: Approval (Funds may be put on hold).5. MB M: Approval.6. M C: Fill order and ship.

15

Credit Card Transactions (con’t)

Consumer: C Consumer’s Bank: CBMerchant: M 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.

16

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.

17

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).

18

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.

19

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.

20

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.

21

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

22

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]

23

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’.

24

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.

25

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).

26

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.

27

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.