Secure Electronic Payments

6/5/2006 http://Amir.Herzberg.name 1

Secure Electronic Payments

Last updated: Monday, June 05, 2006

© Prof. Amir HerzbergComputer Science Department, Bar Ilan University

http://AmirHerzberg.com


Agenda

� Introduction to e-payments� Parties, accounts, requirements� Final, conditional or pending (cleared)

� Credit card payments� SSL Payments� First Virtual� SET� SSL+Approval (e.g. Verified by Visa)

� New Payment mechanisms� Final payment protocols� Supporting multiple Payment Service Providers (PSPs)

� Micropayments - Minimizing Expenses:� Disputes and chargebacks costs� Customer acquiring and support costs� Computation and communication costs

� In next set of foils: � Anonymous payments (digital cash / e-cash)� Final/conditional payments (Igal’s work)

� Conclusions and forecast� Extra: Mobile Payments


Introduction to Payments: Parties

Buyer / PayerSeller / Payee

Payment Service Provider (PSP)Bank, Telco, ISP, …

Broker, Billing system, …

PSP


Basic Account State

Buyer/Payer

(Bob/B)

Seller/Payee

(S)

PSP

AvailablePendPay

Available

PSP.Available[customer]PSP.PendPay[customer]


Payment – Basic Requirements� Integrity

� Conservative available funds

� PSP.Available[c]@t ≥ c.Available@t ≥ 0

� Conservation of funds:Σ PendPay + Σ Available = Constant

� Authorization

� All payments authorized by payer

� Optionally also by payee

� Reliability, liveness

� Payments complete or fail in bounded time

� Funds don’t stay in `PendPay` forever

� Payments succeed if funds, communication OK


Additional requirements, properties

� Receipts (evidences): of payment, failure� Deposit / withdraw� Known (Fixed? Low?) fees� Multiple PSPs� Multiple currencies� Efficiency / cost� Privacy / Anonymity [from seller, PSP]� Service guarantees / Availability � Online or offline PSP

� Offline: final, conditional or pending (cleared)


Final Payments� Payee receives Pre-authorized Payment

� Already authorized by PSP

� Payee validates payment (locally)

� Payment is final

� Payee may need to deposit (within given period)

� Examples:

� Goods, Gold, etc.

� Cash (merchant validates cash is authentic; PSP=Govt’)

� Certified checks, bank notes, etc. (same, but PSP=bank)

� Payee validates payment authorization:

� Signed (digitally)

� Authenticated (PSP-Payee shared key) - MAC


Conditional Payments� Same as final payments…

� Payee receives Pre-authorized Conditional Payment

� But: PSP moves funds only if/when condition holds

� Useful for:

� Payment on future date

� Ensure delivery of (digital) goods – fairness to payer (buyer)

� Currency exchange

� Indexed payments

� Bonds, futures, other financial instruments

� Lottery

� …


Pending (Cleared) Payments� Payee receives Payment Order (PO) from Payer

� Optionally: Payee validates payment order (locally)

� Payee may deliver goods

� Offline but risky

� Payee clears payment with PSP

� PSP move funds to payee’s Available balance

� Payment is final after receiving authorization from PSP

� Payee adds funds to available

� Examples:

� Checks

� Charge (credit) card


Credit Card Payments

Buyer Seller6579 4763 2113

Issuer

Card#, signed slip

Card#, signed slip, $

Card#, $

Card#, statement

Issuer Acquirer (Payment Gateway)


`Mail Order / Telephone Order (MOTO)`

or `Card Not Present` Transactions (Web, phone, mail)

Buyer Seller6579 4763 2113

Issuer

Card#, $

Card#, $

Card#, $

Card, statement

Issuer Acquirer (Payment Gateway)


SSL Payments

SSL encrypted

Credit Card Number

Credit Card Number

Acquirer (Payment Gateway)

Issuer


SSL Based Payments

� Use SSL to securely transfer credit card numbers

� Trivial deployment (merchant decision).

� No client software required (SSL is in browser).

� Built on top of the existing credit card infrastructure.

� By far, the most widely used method.


Credit Card via SSL: Problems

� Use of server as oracle to test guesses of card#s

� Hacked or fraudulent merchants� Expose card#s or charge beyond customer expectations

� Customer can dispute (no signature on slip)

� Very high dispute rates

� Especially for online content and services – 20-60% � Possibly due to merchant fraud, misleading (porn, gambling)

� Very expensive� Merchants – high fees, liability for refunds

� Banks and credit associations –dispute resolution costs (~50$)


Current Practice:

Penalize `Bad` Merchants� Most disputes due to few `bad` merchants

� Incorrect/unclear charging practices

� Problematic service or merchandize

� Solution: high penalty rates for disputes� Typical: 100$/dispute when disputes>2.5%

� Get rid of problematic merchants

� Merchants may still `take money and run`

� Does not prevent consumer fraud

� Penalizes honest merchants� Allows `framing` of merchants


Consumer Merchant

First Virtual

Net Server

1. FV# (First Virtual Number)

2. FV#,

Amount($)

6. Approve

(E-mail)

5. PaymentID,

Amount($)

(E-mail)

First Virtual

CC Server

Credit

Card

ProcessorCC#,

Amount($)

Firewall

7. FV#, Amt($)

3. Valid

4. Goods / services

First Virtual’s Payment System

Q: Criticize!


SET Credit Cards Protocol Standard

� SET: Secure Electronic Transactions

� Provides secure `virtual slip` to merchant

� Based on digital signatures and certificates, and crypto hash functions

� Merge of (similar) proposals from IBM (iKP, 2/95) , Microsoft/Visa (STT, 9/95)

� Defined by Visa and MasterCard (draft 2/96, 1.0 at 5/97), help from IBM, Microsoft, Netscape, GTE.

� Not widely deployed


SET Payments

CertI ,k,

CertB=SignI.s(hk(cc#),B.v)

SignB.s (h(OI)||EA(PI)), k,

CertB , CertI , OI, EA(PI)

PI and CC#

EA(PI), SignB.s (σ), k,

h(OI), CertB , CertI

CertA

Buyer (B)

Issuer (I) Acquirer (A)

CertA=SignCA.s(“Acq.”,A.e)

OI=Order Information PI=Payment Instructions

CA

CertA

CertI=SignCA.s(“Iss.”,I.v)

Seller (S)


Payment Instructions PI , Order Information OI

� OI=Order Information: what is bought

� Authenticated/signed to merchant

� Private, not to be sent to bank / acquirer

� PI=Payment Instructions (`slip`)

� Price, CC#, expiration date, date, TransactionID

� CC# (usually) not revealed to merchant

Buyer

SignB.s (h(OI)||EA(PI)), k,

CertB , CertI , OI, EA(PI)


SET Certificates� X.509 Public Key Certificates

� Certificate hierarchy: Root � Brand �Area�Bank�Entity

� Several SET extensions, e.g.:

� HashedRootKey (only in root certificate; contains hash of next root key)

� CertificateType (Entity – CA/issuer/acquirer/merchant/cardholder)

� CardHolderCertificateRequired

� Revocation

� CA’s keys: revoked, using CRL

� Merchant, Acquirer/gateway: not revoked; use short expiration term, esp. for key exchange

� Cardholder certificates not revoked � Too many; revoke account instead


Cardholder (Buyer) Certificate� No reason to identify cardholder by name

� Physical cards contain name to allow merchant to use auxiliary identification means (e.g. ID card)

� `Credit cards is not to be used for identification`� Liability concern

� Buyer certificate binds public key B.v to `blinded` CC#: hk(CC#)

� On purchase, send encrypted CC# and k to gateway

� Requirements from blinding function hk(CC#):

� Do not expose CC#

� No collision: infeasible to find x, y s.t. hk(x)= hk(y)

� Or certificate for x will allow charging of y!

� Satisfied e.g. if hk is commitment function

� In SET: hk(CC#)=HMAC_SHA1k(CC#)

� Secure under `random oracle methodology`


SET Pros and Cons� Pros

� Standard by Visa and MasterCard.

� Uses existing credit card backend processing

� This was also a major constraint

� Uses signatures.� Cons

� Chicken, egg and farmer problem: requires adoption and software by merchant, buyer, and both their banks

� No benefit to early adopters

� VISA/MC tried to fix this but too little, too late

� Complex, expensive certification processes

� Fat wallets, complex spec

� Tiny/null market share


Lessons from SET � Even a standard won’t succeed without…

� Simplicity

� Ease of use

� Migration path (Chicken and Egg)

� Incentives to early adopters

� Critical Mass of buyers, sellers, transactions

� Post-SET efforts:

� 3D SET, 3D Secure,…; SET wallet server

� SSL + Payment Approval

� Verified by Visa (SSL password protection)


Credit/debit cards:

SSL+Approval Approach

Payment Approval[and one-time alias]

Use of one-time alias card numberand/or a fixed, non-secret alias card number.

Issuer Acquirer


Properties

� Merchant and acquirer unaffected

� Client software optional

� Multiple vendors and variants

� Credit cards only

� Merchant does not perceive added security� Optional merchant validation

� One-time alias: conflicts with fraud-detection heuristics


Verified by Visa (VbV)� Enter credit card on

checkout (as usual)

� If buyer and seller registered to VbV: � Send details to Visa (Get

request over SSL)

� Visa returns password form

� Personal message

� Security? � Ok if seller Ok/passive

� Fails against MITM (seller)

� Illusion of security, harder to deny… bad for consumers


Credit Card Payments - Status

� SET seems doomed

� SSL is widely used

� Several SSL+Approval efforts, including:� MasterCard: Secure Payment Application (SPA)

� Amex, Discover (and Isracard)

� Visa: `Verified by Visa`� Widely deployed, not often used


New Payment Mechanisms� Credit cards are the only payment mechanism

widely used over phone/Net� Motivations for other mechanisms?

� Reduce costs

� For small value transactions – Micropayments� Credit/debit card have min-fees of 10-30 cents

� For B2B payments – even 1% is a lot of money…� Allow personal/small (untrusted) merchants

� With credit cards, `bad` merchant can steal credit cards, `take money and run`

� While merchant is vulnerable to disputes� New features, e.g. anonymous payments (`e-cash`)� Final Payments – no disputes, chargebacks, penalties

� And conditional payments, too


Online Final/Conditional Payments

Seller

Internet

Identify Order Authorize

PSPBuyer Authorized PO

Most successful: PayPal• Person to Person (or: small business)• Main application: auctions (eBay)• Security via (secure) connections to PayPal’s web server, password• Simple to deploy and use


2.

Ord

er

SellerBuyer

1. Offer

3.

Au

tho

rized

PO

4. Authorized PO

5. Goods / services

PSP

6. Deposit PO

Offline Final/Conditional Payments


Multiple PSPs

� Acquiring customers is expensive� Global Availability and Critical Mass are Critical for

any instrument (cash, checks, cards,...)� Greatest advantage/slogan of Visa, MasterCard� Merchants need many buyers� Buyers want one account, buy from all � Payment system providers need many transactions

� Easy if there is one PSP in the world…� Business approach: make one huge PSP

� Many failures (but: PayPal )

� Technical approach: Interoperability among Multiple PSPs

� Like Visa, MC (vs. Amex, Diners)


Open Payment Network

� Interoperability among all PSPs (buy anywhere)

� Connect with one PSP, provide to all

� Focus on Offline Final/Conditional Payments

B S

P1 P5

P2 P4

P3


Building the PSP Network…

Design Principles� Accountability (no finger-pointing): risks only from partners you

choose (and trust)

� Trust and disputes only with partner (direct)

� Customer may fail to pay PSP

� PSP may fail to pay merchant or peer PSP

� No other risks; no finger-pointing, global trust

� Good fences make good neighbors

� Precise agreements, automated resolution with partners

� Avoid/resolve disputes, reduce costs & risks

� Communicate using trusted, guaranteed delivery protocol (delivery of messages within bounded time)

� Analysis not complete yet


Main Tool: Payment Certificate (PC)

� PC=< v, path, expire, max, net, x, id, by, for, σ> is a payment

certificate of signature scheme S where:

� v is validation key (of S), path is a list of identifiers (PSPs), expire, x

are time, max is amount, net:amount�amount, by, from and id are

identifiers

� PC is signed with key v’ under scheme S if S.validv’(PC/σ, σ)

� PC is a commitment by PSP PC.by to PC.for

� PC.for (beneficiary) : customer or another PSP

� To pay PC.for total of min(PC.max,Σ PC.net(POi.amt)) upon

presentment, at time t<PC.expire, of payment orders {POi} s.t.:

� For every i holds: S.ValidPC.v(POi), t<PO.expire-PC.x

� (PC.path||by||for) is a prefix of PO.path

� For every i,j s.t. i≠j holds POi.id≠POj.id


Payment Routing between two PSPsPC= Payment Certificate

5. PO (path={IAS}…)

σ=S.SignI.v(PO) 7. σ, PO

1. PCIA (by=I, for=A,

v=I.v, path=λ)

2. PCIS (by=B,

for=S, v=I.v

path=I)

Issuer (I) Acquirer (A)

Seller S

6. σ, PO

8. σ, PO

Buyer B

3. Offer, path=IAS

4. Offer,

path=IA,

Approval


Payment Routing - Multiple PSPs

σ,

PO

PO, σ

Offer,

net, path,

Approval

PO,

σ

I

A

Offer, net(x)=0.8x-1, path=IZAS

X Y

Z

PC (by=I, for=X,

net(x)=x…)

PC (by=X,

net(x)=0.9x…)

PC (by=Y,

net(x)=0.8x…)

PC (by=Z, for=A,

net(x)=0.9x-1…)

PC (by=I, for=Z,

net(x)=x…)

PC (by=A,

for=S,

net(x)=0.8x-1…)


Agenda� Introduction to e-payments

� Parties and requirements

� Credit card payments� Mail Order Telephone Order (MOTO)� SSL Payments� First Virtual� SET� SSL+Approval

� New Payment mechanisms� Final payment protocols� Supporting multiple Payment Service Providers (PSPs)

� Micropayments - Minimizing Expenses:� Disputes and chargebacks costs� Customer acquiring and support costs� Computation and communication costs

� Conclusions and forecast� Extra: Mobile Payments


Why Micropayments?

• Problem: how to charge ‘cents per click’?

• To sell low cost content and services

• Existing options:

• Credit cards:

• Consumer: security, overhead, privacy

• Merchant: cost (25c per min), chargebacks

• Bank/association: disputes, merchant fraud

• Advertising - limited ‘per view’ returns (and shrinking – 3c (98) to < 1c (2000)…)

• Also… disturbs customers, hurts objectivity, wastes bandwidth

• Subscriptions - not done by most customers

• Micropayments may complement


Minimizing Expenses

� Disputes, Chargebacks, and their processing

� Use final payments (evidences, no disputes)

� May also reduce book-keeping and auditing

� Customer acquiring and support

� Processing and communication

� Point-of-Sale integration

� Credit risk


Final Payments: No Disputes

� Customer: I never approved this payment

� PSP: Unauthorized Overspending

� Customer: Delivery and/or Quality

Problem

� PSP: Consumer Default

No long-term

Merchant-Customer

Relationship

Secure Payment Authorization

Secure Payment Approval


Minimizing Expenses

� Disputes, Chargebacks, and their processing

� Also: Book-keeping and auditing

� Customer acquiring and support

� Processing and communication

� Point-of-Sale integration

� Credit risk


Processing and Communication Costs

� Processing: (online) Public Key Signatures

� Natural choice for secure payment approval and authorization (with evidences)

� Alternatives: offline signatures, no evidences,…

� Communication:

� How many messages

� PSP authorizes online or not (offline)

� Aggregated/probabilistic deposit (to save processing and communication costs)


Reducing Cost of Signature Validation

� Motivation: save computations

� Reality: public key operations…� Are not significant with modern processors, esp. clients

� Except, maybe, for weak mobile devices

� But – several nice techniques…� Avoid online public key signing: sign one-time-signature

PK offline, use it to sign online efficiently� Yet: main problem is validation (servers) not signing

� Random (sampling) validation� Appropriate for long-term relationship, e.g. PSP-PSP

� Batch (off-line) signature validation� Efficient validation of multiple signatures (e.g. for RSA)

� Other techniques avoid all public key operations …


Avoiding Public Key Operations

� Use only shared key authentication- MAC� Lose non-repudiation (evidences)

� Use only MAC until reaching aggregated limit; then sign � limiting disputable amount

� Sign hash chain: � 1 cent � SignA(1c/hash, h8(x), ID, Expires,…)

� 2 cents � same, plus h7(x)

� 8 cents � same, plus x


Avoiding Online Authorization

� No payment authorization by PSP� Seller’s risk; problem: sporadic relationship

� Merchant may ask authorization (randomly/limit/…)

� Broadcast of `black list` of over-spenders ??

� Enforce balance limit by tamper-proof module� Tamper-proof modules are expensive, cumbersome

and sometimes broken anyway

� Pre-authorization: PSP authorizes payments (till limit) to specific merchant� Buyer can authorize up to limit by herself

� Exercise: modify final-payments protocol for this


Aggregated/Probabilistic Deposit

� Goal: save processing and communication

� Instead of depositing each cent…� Deposit only the sum of many micropayments, or

� Deposit 1$ with probability 1/100

� Valuable mainly with multiple PSPs� Longer deposit path; involve (most) PSPs only rarely

� Solutions:� Buyer-seller aggregation (repeat-buy only; like hash chain)

� Buyer pays with `lottery tickets`

� PSP pays `lucky sellers` [MicaliRivest02]� If pre-authorized: seller can cheat using phony customers

� Buyer-PSP to seller Aggregated/Probabilistic payment


Buyer pays with `lottery tickets`� Buyer pays in average the desired price

� Each purchase is either one large amount or none

� Seller coin-toss:

� Seller provides h(x)

� Buyer selects few (say 5) random bits, y[1..5]

� Payment is SignA(10$, “if 5 LSb of x=“, y[1..5], h(x))

� No need to deposit payments which resulted in no value� Save communication and processing (of most deposits)

� Problems: � Fails if seller can find (many) collisions in h

� Requires `strong collision resistance`

� This can be fixed: customer chooses random key to h (extra flow)

� Buyer acceptance, convenience, trust

� Seller still needs to confirm buyer has funds (or assume risk) � No point checking only for buyer who are supposed to pay…

� Payments must be authorized (or pre-authorized) by PSP


Buyer’s PSP pays with `lottery tickets`

� If buyer’s PSP authorizes each payment online...

� As e.g. when PSP is also mobile gateway

� Then buyer’s PSP can sell `lottery tickets` to merchant

� Addresses all problems identified above…

� Interaction btw merchant and buyer’s PSP:

� Buyer’s PSP selects key k to hash function (e.g. periodically)

� Merchant to send hk(x) to PSP

� Avoid interaction using `hash of signature` technique [MR02]

� But merchant typically sends offer to customer/PSP anyway

� PSP sends random bits (as part of payment)

� How to support pre-authorized payments?


Buyer-PSP to Merchant Aggregation

� To support Buyer-PSP pre-authorization…

� While minimizing number of deposits – for multiple PSP scenario

� Idea: merchant periodically aggregates payments from same buyer-PSP

� PSP exchanges them with one payment authorization (for the total amount)

� Simple, efficient and deterministic

� Easier to manage/debug/`sell` then `lottery`…


Conclusion

� SSL / TLS CC payments are not perfect… but exist

� SET was too complex, not enough value to parties

� Existing efforts: partial, fragmented

� PayPal: centralized, weak security – but simple � success

� Final payments? Interoperability among PSPs?

� Many precedents in history of payments

� What we didn’t cover (yet?):

� Anonymous payments (digital cash)

� Provable secure payments (Igal’s work)

Secure Electronic Payments

Documents

Transcript of Secure Electronic Payments