Software Infrastructure for Electronic Commerce Electronic Payment Systems

Software Infrastructure for Electronic Commerce Electronic Payment Systems Professor Fred B. Schneider Dept. of Computer Science Cornell University

Goals l l Learn about properties of payment systems. Exposure to extant payment systems: – What services do they provide? – What risks do they introduce? l Understand forces that shape when/whether a payment system will enjoy widespread adoption. 1

E-Payment Potential l For existing business y. Reduce order-taking costs with automation. y. Project modern and competitive image. by substituting network for: y. Catalog and/or y. Ordering. l For new business: – Exploit immediacy of the networked communication to convert to auction-based commerce. – Tailor the “store” to individual customers: y. Monitoring customer activity by web server allows “knowing your customer” (as done today with affinity cards). y. Increased need for data mining. 2

E-Payment Risks to Customer l l 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 l l l 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 l Technology providers have incentive to deploy new, non-interoperating, systems. y. Constantly shifting alliances. y“Big players” sought to endorse various “standards”. y. Standards bodies (e. g. IETF) are unable to exert leadership. l 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: y Confidentiality, y Integrity, and y 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 l 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. l 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 l Augmenting lower levels: – IPv 6 (“IPSEC”)… Slowly being deployed. l Modifying the application: – S-HTTP (rip) – Secure Socket Layer (SSL) y. Netscape strategy: Promote e-consumer fear, which pressures e-merchants to use Netscape web servers supporting Netscape’s SSL. y. SSL 3. 0 is basis for IETF Transport Layer Security (TLS). 9

Transaction Security: Example: SSL l Functionality: – Secrecy of in-transit messages. – Integrity of in-transit messages (thru MAC) – 2 -way authentication l l 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 SSL 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. 1 01 1 101 0 0 11 1 0 0 1 1 10 1 0 01 1 0 00101 00 1 1110 11 0 1 110 11

Historical Perspective l 1118 – 1307 AD: Knights Templar support pilgrimage trade: y. Deposit funds with local Templar and receive coded chit. y. Templar representatives along the journey would make expenditures, re-code the chit, and return to owner. y. At journey’s end, chit was presented to local Templar and account would be settled. l l l 1928: Farrington Manufacturing Company (Boston) introduces “charge plate” embossed with customer name and address. 1949: Alfred Bloomingdale, Fran Mc. Namara, & 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 l Who assumes the risk? y. Buyer? Merchant? Intermediary? l 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. l What is per-transaction cost? y. 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 l With ordinary credit cards: Risk associated with time gap between – merchant paid -and– buyer pays credit card bill. l First Virtual commerce model: Delay payment to merchant for 90 days. y. Allows buyer-merchant dispute period to expire before merchant is paid. 18

E-Payment Systems Example: Digi. Cash 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 Digi. Cash Coin Minting l 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. l Bank has PUBLIC/private key pair for each denomination. They are inverses. – E. g. WASH/wash, LINC/linc, JEFF/jeff, … l Coins have self-checking serial numbers. – E. g. Number in 2 halves: 12345 54321 20

E-Payment Systems Digi. Cash Coin Minting Protocol Payer: Invent new coin self-checking number n; Invent and store random number r; Payer Bank: B = n * (r. WASH) Bank: Debit payors account by $1. 00; B’ = Bwash = (n * r. WASH)wash = nwash * r. WASH*wash = nwash * r 1 [Bank doesn’t learn n. ] Bank Payer : B’ Payer: Coin is B’/r (= nwash ) [n signed by bank is coin] 21

E-Payment Systems Digi. Cash Coin Checking Protocol l l 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: y. Has n already been spent? y. Save n for future double-spending checks. y. 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). y. Each merchant issues merchant-specific script. y. Buyers get script from broker. y. Broker obtains script — in bulk — from merchant. y. Uses hash rather than encryption to prevent forged script. 23

E-Payment Systems SET (Secure Electronic Transactions) l Collaboration between VISA, Mastercard, American Express – Uses many keys y 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 … l l 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