e-payment ect 582 robin burke. outline characteristics select protocols

Download E-Payment ECT 582 Robin Burke. Outline Characteristics Select protocols

Post on 16-Jan-2016




0 download

Embed Size (px)


  • E-PaymentECT 582Robin Burke

  • OutlineCharacteristicsSelect protocols

  • Characteristics of payment systemsSecurity / PrivacyConvenienceCostOverheadInteroperability

  • Security / PrivacyAnonymousseller or buyer authentication required?Non-repudiationsecure receipt generated?Securityagainst theft?against forgery?against double-spending?Privacyproperties of transaction hidden from involved partiesFail-safeis money lost / created in system failure?

  • CostFixed costcost to adopt the technologyTransaction costcost per transactionFloataccrual of accumulated interestRiskpossible financial loss to buyer / seller

  • ConvenienceComplexitynumber of steps to complete transactionTwo-waypeer to peer payment possibleOff-lineno need for connection to third-party during transactionAccountdoes one or both parties need a special account established in advance?Respendabilityno intermediate steps between receiving and spendingPortablenot location-dependent

  • InteroperabilityExchangeableone type of currency for anotherTransferablecan be transferred from individual to individualDivisiblecan be subdivided into smaller unitsHardware independentno special hardware requiredMonetary valuebuilt-in value

  • OverheadScalabilitytransactions / usersDelayhow long does the transaction take?Hardware / software requirements

  • ExamplesCashCheckCredit cardOnline credit cardMondexPayPalDigital wallet

  • FrameworkPlayerswho is involvedProcesseswhat is the protocolPropertiescostsrisksetc

  • CashPlayersbuyer / seller (Bob & Susie)Processsecure documentfixed amountphysical exchange

  • Cash propertiesanonymitydivisibilityexchangablelow costrepudiable, without receipt steplow techmonetaryuntraceable

  • CheckPlayersBob, SusieBob's bank BK, Susie's bank SKVerification service VProcessphysical exchangesecure document with biometric IDSusie may verify with V before acceptingSusie deposits with SKSK settles with BK via ACHBob's account at BK debited

  • Check propertiesAccounts requiredBob and SusieTraceableNon-anonymousMedium cost10-20Risk to seller if verification not in placeNon-transferable (in theory)biometric authentication

  • Credit cardPlayersBob, Susie, SK (acquirer)Card issuer BCTransaction processor TSetupSusie must have card processing accountSK leases POS hardware and network accessBob must have credit card

  • Credit card cont'dPresentationBob presents card orBob presents card number plus other informationAuthorizationSusie contacts SK with card infoSK contacts TT contacts BCBC can accept, deny, etc.CaptureTransaction is committedgoods acceptedAuthorization steps happen again with capture flagcard balance debitedSettlementBC transfers money to SKBillingBC sends Bob a monthly billBob pays BC

  • Credit card cont'dnon-anonymousnon-transferablesecurity weak esp. NSPdesigned to thwart simple theftoff-line = low securitynot interoperablelow cost / low risk for buyerBC absorbs fraud risk

  • Online credit cardsame as before exceptweak buyer authenticationphysical card never presentphysical signature never presentsecurity reduced from biometric to dataweak seller authenticationmajor fraud opportunitySSL protects only passive attacks on IP traffic

  • SETSame players as credit cardCentral ideaSusie only needs to know that she will get paidBob's card number not essentialBC only needs to know enough to validate the transactionSegment the transactionPart for SusiePart for BC

  • SET cont'd

  • SET cont'dProcessSusie and BC have public keysBob encrypts and signs an order O to Susie Bob encrypts and signs payment information P to BC P is sent through the acquirer to BCBC decrypts and validates the transactionSends Susie verification and transaction idSusie presents transaction id to acquirer for settlement

  • SET cont'dPropertiesauthentication of sellernon-disclosure of credit card #non-disclosure of order detailsenhanced privacyhardware / software requirementelectronic walletSlow adoption of SETrequires PKI (hierarchical)requires client-side softwareincompatible wallet implementations

  • MondexPlayersBob, SusieSetupBob and Susie both have Mondex smart cardsBob has downloaded cash tokens to his Mondex cardBob or Susie has a Mondex terminalmoney exchange deviceProcessconnect cards to terminalenter respective PINscards authenticate each other's certificatesSusie's card generates signed purchase requestBob's card acknowledges request and deletes stored tokensSusie's card adds tokens

  • Mondex cont'dCharacteristicslimited maximum storagereduces danger of money launderingsome buyer riskstolen card is lost cashrespendabletwo-wayconvenientdependent on secure hardwarerisky assumption

  • Secure hardwarePrivate key stored in devicekey used to authenticate as "real" Mondex devicekey used to encrypt memory contentsSimilar to private key token for PKI BUTowner has incentive to break inHow to buildpackaginginternal consistency checks"reset on fault"

  • Attacks against secure hardwareProblemphysics of device cannot be hiddenAttackers canetch new circuitryremove deletion stepalter encryption algorithmmonitor encryption to capture secret keypower consumptiontimingbus probe

  • Should we worry?Questionwhere does "expected payoff" > "investment to break"Answerif Mondex becomes widespreadchip tampering = printing moneyAttackersClass I capable outsiderClass II knowledgeable insiderClass III determined organization

  • eCashPlayersBob, SusieSetupBob and Susie have eCash accounts and eCash software or smart cardBob loads secure "coins" to walleta coin = a $$ amount, an id and a digital signatureProcessBob transfers coins to SusieSusie deposits in account

  • CharacteristicsAnonymousTwo-wayNon-traceableRespendableForgerycryptographic problem

  • AnonymityCoin only has bank's identifierBank doesn't know who originally withdrew itwhose hands it has passed throughProblemdouble spendingbank can detect but is Susie or Bob at faultwithdrawalwhen coins are given to Bob, ids could be recorded

  • Blind signatureProblemsign a document without looking at itSolutionmultiple message by a factor M*Fsign M*F creating M*F + Sfactor out F leaving M + S/Ffor certain algorithms S/F is the correct signature for MBob cancreate a message = "$1"blind ithave bank sign itdeduct $1 from Bob's accountcreate coin

  • Cut and chooseBob could alsocreate a message = "$100"blind ittell the bank it says "$1"have bank sign itSolutionBob creates n messagesBank examines n-1 at randomif they all say "$1"then the bank signswe pick n to be as large as necessary for securitymay depend on size of transaction

  • Double spendingWhat if Bob spends the same coins twice?What if Susie deposits the same coins twice?Bank can detectsame id deposited twicecan't distinguish

  • Conditional anonymityBob encrypts self-identifying information in the coinbank can verify just like $ amountWhen spendingBob discloses 50% of the key used to decrypt personal infoif he spends twice, his identity becomes known to the bankA similar device can be used to protect against double deposits

  • Double spending

  • eCash viabilityUntraceability + anonymity + virtualitymany opportunities for crimegovernments hate itDigiCashfounder Chaumwent bankruptsome patents will expire soon

  • PayPalPlayersBob, Susie, PayPalSetupBob needs a PayPal accountlinked to a bank account or credit cardProcessBob uses the PayPal application to send money using Susie's email addressSusie can access her funds by creating a PayPal account linked to her email address

  • CharacteristicsLow transaction costRespendableOn-line onlyViralrecipient must get an account to get paidTraceable, non-anonymous

  • Digital walletThe cure-all that wasn'teWalletout of businessJava WalletdiscontinuedMS Passportno longer includes credit card infoW3C digital wallet initiativediscontinued

  • Why?information not portablesingle machineinformation too portablethird partyinsufficient trust in client software

  • ConclusionVery few e-payment success storiesCredit cardsapproximately 1.8 billion in fraud on-line in 2002still the dominant mechanismReasonsconveniencealready in uselow buyer risk