software infrastructure for electronic commerce electronic payment systems professor fred b....
TRANSCRIPT
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.