Software Infrastructure for Electronic Commerce Electronic Payment Systems

1
Software Infrastructurefor Electronic
Commerce Electronic Payment
Systems

• Professor Fred B. Schneider
• Dept. 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 customers site, glean
  information about the customer, and misuse that.
• E.g., Merchant offers higher prices based on
  customers 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 SecuritySome 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 SecurityTechnical Approaches

• Problems to solve
• Confidentiality,
• Integrity, and
• Authentication.
• Two general solution approaches
• Add support for encryption
• Augment lower levels of system with support for
  encryption.
• Include support for encryption in applications.

Net
9
Transaction SecurityConsequences 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 SecurityExamples

• 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 Netscapes SSL.
• SSL 3.0 is basis for IETF Transport Layer
  Security (TLS).

11
Transaction SecurityExample 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
• Opening handshake
• Application dialog
• Closing handshake
• To use SSL w browser
• http//www.company.com/ ? https//www.company
  .com/

12
Digital Payment Systems

• Digital payment system Allows transfer of value
  without transfer of physical objects.
• Payment by bits rather than atoms.

10100 101 1111 01
1101011010101101011
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 journeys 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 Consumers Bank CB
• Merchant M Merchants Bank MB
• Making a Purchase
• 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.

15
Credit Card Transactions (cont)

• Consumer C Consumers Bank CB
• Merchant M Merchants Bank MB
• Merchant Receives Payment
• M ? MB Batch of charge slips
• MB ? CB Request for .
• CB ? Clearinghouse Debit consumer
• credit
  settlement acnt.
• 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 SystemsExample 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 wouldnt
  meet credit card company standards.
• Shifts burden of trust to buyer, making it easier
  to become merchant.

19
E-Payment SystemsFirst 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 SystemsExample 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 buyers local disk or banks local disk
• Forgery anonymity is a hard problem!!!!
• Hard to copy a bank note anyone can copy a bit
  pattern.

21
E-Payment SystemsDigiCash 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 SystemsDigiCash 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 rWASHwash
• nwash r1 Bank
  doesnt learn n.
• Bank ? Payer B
• Payer Coin is B/r ( nwash ) n
  signed by bank is coin

23
E-Payment SystemsDigiCash 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
  doesnt want to spend B.

24
E-Payment SystemsExample 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 SystemsSET (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, OReilly Associates, Inc.
  Cambridge, 1997.