Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Software Infrastructure for Electronic Commerce Electronic Payment Systems Professor Fred B. Schneider Dept. of Computer Science Cornell University."— Presentation transcript:

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

2 1 Goals l Learn about properties of payment systems. l 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.

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

4 3 E-Payment Risks to Customer l Merchant could misuse information provided for transactions by customer. l 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 4 E-Payment Risks to Merchant l Customer could really be a competitor attempting to learn prices or strategy. l Customer could be an imposter, and bill will not be paid. l 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 5 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 6 Transaction Security: Some Political Realities l Technology providers have incentive to deploy new, non-interoperating, systems. yConstantly shifting alliances. y“Big players” sought to endorse various “standards”. yStandards 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.”

8 7 Transaction Security: Technical Approaches Problems to solve: yConfidentiality, yIntegrity, and yAuthentication. 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 8 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.

10 9 Transaction Security: Examples l Augmenting lower levels: –IPv6 (“IPSEC”)… Slowly being deployed. l Modifying the application: –S-HTTP (rip) –Secure Socket Layer (SSL) yNetscape strategy: Promote e-consumer fear, which pressures e-merchants to use Netscape web servers supporting Netscape’s SSL. ySSL 3.0 is basis for IETF Transport Layer Security (TLS).

11 10 Transaction Security: Example: SSL l Functionality: –Secrecy of in-transit messages. –Integrity of in-transit messages (thru MAC) –2-way authentication l Separate algorithms and keys for encryption, data integrity, authentication due to U.S. export restrictions. l Actual Operation: 1.Opening handshake 2.Application dialog 3.Closing handshake To use SSL w browser… … SSL TCP/IP App SSL TCP/IP App SSL

12 11 Digital Payment Systems Digital payment system: Allows transfer of value without transfer of physical objects. Payment by bits rather than atoms. 1101011010101101011 10100 101 1111 01 00101 00 1 1110

13 12 Historical Perspective l 1118 – 1307 AD: Knights Templar support pilgrimage trade: yDeposit funds with local Templar and receive coded chit. yTemplar representatives along the journey would make expenditures, re-code the chit, and return to owner. yAt journey’s end, chit was presented to local Templar and account would be settled. l 1928: Farrington Manufacturing Company (Boston) introduces “charge plate” embossed with customer name and address. l 1949: Alfred Bloomingdale, Fran McNamara, & Ralph Snyder conceive of “universal” charge card (“Diners Club”) for entertaining. l 1958: American Express & Carte Blanche created.

14 13 Credit Card Transactions Consumer: CConsumer’s Bank: CB Merchant: MMerchant’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 14 Credit Card Transactions (con’t) Consumer: CConsumer’s Bank: CB Merchant: MMerchant’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 15 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 16 E-Payment System Characteristics l Who assumes the risk? yBuyer? 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? yMight pay more to reduce risks (if greater value is at stake).

18 17 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 18 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. yAllows buyer-merchant dispute period to expire before merchant is paid.

20 19 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 20 E-Payment Systems DigiCash 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

22 21 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 * (r WASH ) Bank:Debit payors account by $1.00; B’ = B wash = (n * r WASH ) wash = n wash * r WASH*wash = n wash * r 1 [Bank doesn’t learn n.] Bank  Payer : B’ Payer: Coin is B’/r (= n wash ) [n signed by bank is coin]

23 22 E-Payment Systems DigiCash Coin Checking Protocol l Bank stores serial numbers for coins that have been spent. l Payer receiving coin B’ (=n wash ) checks it: –Is B’ correctly signed? Use public key WASH to check. –Does (B’) WASH have correct form: 12345 54321? –Communicate with bank: yHas n already been spent? ySave n for future double-spending checks. yReturn a fresh coin (new serial number) if payer doesn’t want to spend B’.

24 23 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). yEach merchant issues merchant-specific script. yBuyers get script from broker. yBroker obtains script — in bulk — from merchant. yUses hash rather than encryption to prevent forged script.

25 24 E-Payment Systems SET (Secure Electronic Transactions) l Collaboration between VISA, Mastercard, American Express –Uses many keys y2 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 25 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 26 For additional reading … l Web Security Sourcebook. Aviel D. Rubin, Daniel Greer, Marcus J. Ranum. J. Wiley, New York, 1997. l Web Security and Commerce. Simson Garfinkel with Gene Spafford, O’Reilly & Associates, Inc. Cambridge, 1997.

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

Similar presentations

Ads by Google