payment authentication and mobile payment systems n.
Skip this Video
Loading SlideShow in 5 Seconds..
Payment Authentication and Mobile Payment Systems PowerPoint Presentation
Download Presentation
Payment Authentication and Mobile Payment Systems

Loading in 2 Seconds...

  share
play fullscreen
1 / 54
Download Presentation

Payment Authentication and Mobile Payment Systems - PowerPoint PPT Presentation

slone
132 Views
Download Presentation

Payment Authentication and Mobile Payment Systems

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Payment Authentication and Mobile Payment Systems Cmpe 526 Operating System and Network Security Erdem Savaş İlhan Spring 2005 Boğaziçi University Department of Computer Engineering

  2. Outline • Introduction • Security of Electronic Payments • SET • Recent Authentication Practices • Visa 3D Secure • MasterCard SecureCode • Mobile Payments Security • WAP and WTLS • SIM Application Toolkit • Wireless PKI • Offline E-cash with Flexible Anonymity • Conclusion

  3. Introduction • Electronic Payment • Credit • Cheque • Cash

  4. Introduction • Payment information should be secured • Authentication • Authorization • Confidentiality • Non-repudiation • Privacy • Anonymity

  5. SET Protocol(Purpose) • SSL provides a secure channel between the customer and merchant • Cardholder is protected from eavesdropping but not from a dishonest merchant • Merchant is not protected from dishonest users presenting invalid card numbers • Purpose • Provide confidentiality of information • Ensure integrity of payment instructions • Authenticate both the cardholder and merchant

  6. SET Protocol(Overview) • How it works • Cardholder and merchant registers with a CA • Cardholder sends order and payment information • Merchant forwards card information to the bank • Merchant’s bank checks with issuer for payment authorization • Issuer sends authorization to merchant’s bank • Merchant’s bank sends authorization to merchant • Merchant completes the order and sends confirmation to consumer • Merchant captures the transaction from their bank • Issuer bills the consumer

  7. SET Protocol(Properties) • Utilizes cryptography • Provide confidentiality of information • Ensure payment integrity • Enable identity authentication • Digital envelope is used • Symmetric key encryption + public key encryption • Digital certificates • Customer • Merchant • Acquirer • Issuer • Payment Gateway • Encryption speed of DES combined with key management of RSA • RSA modulus 1024 bits • DES 56 bits keys

  8. SET Protocol(Verification) • Merchant verifying purchase request

  9. SET Protocol • Dual Signatures • Merchant sends authorization request to acquirer • Payment instructions + order message digest

  10. SET Protocol(Process in Detail) • SET Process • Merchant sends unique transaction ID (XID) • Merchant sends merchant certificate and bank certificate (encrypted with CA’s private key) • Customer decrypts certificates, obtains public keys • Customer generates order information (OI) and payment info (PI) encrypted with different session keys and dual-signed • Merchant sends payment request to bank encrypted with bank merchant session key, PI, digest of OI and merchant’s certificate • Bank verifies that the XID matches the one in the PI • Bank sends authorization request to issuing bank via payment gateway • Bank sends approval to merchant • Merchant sends acknowledgement to customer

  11. SET Protocol • Cardholder certificates • Signed by a financial institution • Account information and a secret value is encoded with a one-way has into cardholder software (Supplied to payment gateway) • Certificate transmitted to merchants with purchase requests

  12. SET Protocol • Merchant Certificates • Shows that merchant has a relationship with a financial institution allowing it to accept payment card brand • Assurance of a valid agreement with acquirer • Certificates for each payment card brand that merchant accepts

  13. SET Protocol • Payment Gateway Certificates • Encryption key is used to protect cardholder account information • Issued by the payment card brand • Acquirer Certificates • Issues certificates to merchants (May prefer payment card brand to process certificate requests) • Receive their certificates from payment card brand • Issuer Certificates • Issues certificates to cardholders • Receive their certificates from payment card brand

  14. SET Protocol(Problems) • Requires extensive use of digital certificates • Additional software on client side • Bypassing this ignores user authentication • Heavy-weight protocol • Different platforms (i.e mobile) should also be considered

  15. 3D Secure(Purpose) • Frauds and cardholders claiming non-participation • Need to enable issuers for verifying a customer is an authorized cardholder • Authenticate cardholders during online purchases • Use of SSL to protect cardholder account information

  16. 3D Secure(Overview) • Purchase transaction

  17. 3D Secure(Overview) • 1. The cardholder selects goods or services and proceeds to the merchant’s checkout page. • 2. The Merchant Server Plug-in queries the Visa Directory to determine whether authentication is available for the card number. If the card number is in a participating card range, the Visa Directory queries the appropriate Issuer Access Control Server to validate cardholder participation and sends the response back to the Merchant Server Plug-in. • 3. The Merchant Server Plug-in sends an authentication request to the Access Control Server via the cardholder browser. • 4. The Access Control Server queries the cardholder for password. The cardholder enters the password, and the Access Control Server verifies it. • 5. The Access Control Server returns the authentication response to the Merchant Server Plug-in via the cardholder browser and passes a record of the authentication to the Authentication History Server. • 6. The Merchant Server Plug-in validates the response. • 7. If appropriate, merchant proceeds with authorization exchange with its acquirer.

  18. 3D Secure(Issuer) • Account Holder File (AHF): master account database • Is the account participating? • If so, using what methods? • Enrollment Server (ES) • Run by Issuer or his proxy • Sets up online credentials, generates AHF entries • Access Control Server (ACS) • Centralized server site that has two functions: • Tell Merchants whether or not an account is participating • Do the cardholder authentication • Each ACS (site) handles a given range of accounts

  19. 3D Secure(Merchant/Acquirer) • Merchant Plug-in (MP) • Software module that runs within Merchant’s e-commerce web site • Validation Server (VS) • Verifies signed messages • Called by MP • Might be separate server, site, or just part of MP

  20. 3D Secure(Interoperability/Visa) • Directory Server (DS) • Helps MP find an ACS for a given card • Many, many MPs Millions • Many ACS sites (per-issuer) Thousands • Few DS sites Ten(s) • Hosted and managed by Visa • Receipts Server/File • Saves receipts securely • Signed message • Called “receipt” but really a record of authentication • All “receipts” collected by Visa

  21. 3D Secure(Global Authentication Network) Cardholder browser Authentication Credential A VISA Member Bank Card Accepting Merchant Site Directory Server Access Control Server Enrollment Server Merchant Software Receipt Server AHF Global Payment Network Acquirer

  22. 3D Secure(User Authentication) • Issuer gives cardholder a signed “proof of identity” • Message containing result of authentication dialog • Digitally signed by issuer • Cardholder presents “proof of identity” to merchant • Browser posts message back to merchant site • Merchant checks validity of “proof of identity” • Calls Validation Server to check signature • Takes appropriate action according to result and merchant policies

  23. 3D Secure (Conclusion) • Provides user authentication • Current online credit based payments does not provide authentication • Expected to decrease frauds • Mastercard SecureCode architecture is similar to 3D Secure

  24. Mobile Payments(Introduction) • Mobile Payments • Operator payment (i.e. GPRS) • Out of band payment (i.e. involving a financial institution) • Proximity payment (i.e. IC-Cards)

  25. Mobile Payments(Introduction)

  26. Mobile Payments(Technologies) • WTLS • Narrowband optimization for TLS • WIM (Wireless Identity Module) • Performs WTLS related operations • Secret keys, certificates • Implemented as a software on smartcard • WPKI (Wireless PKI) • End entities (EE) and RAs are implemented differently • A new entity: WPKI Portal • EE runs on WAP device • PKI portal can be a dual networked system as a WAP gateway • Translates requests of WAP clients to RA • Interacts with CA over the wired network

  27. Mobile Payment(Technologies) • Merchant server authentication with gateway • Gateway authentication with client (WTLS certificate on client) • Client authentication with gateway with WTLS certificate or signature using WIM with merchant

  28. Mobile Payments(Technologies) • SIM Application Toolkit • Used in SMS based mobile payment solutions • Client and payment server in SMS communication • GSM network acts as an intermediary and authenticates client • Each application message has encrypted payload with security specifications in header • Provides authentication, message integrity, confidentiality, replay detection • No end to end security • Provider and its SMS center must be trusted • Flaw of using 4 digit PIN • Attacker needs to clone the SIM card to forge • J2ME • Stores and processes encryption keys • Application level security • Provides end to end security

  29. Client Web Server WAP Gateway WML CGI Scripts etc. WML Encoder WML-Script WSP/WTP HTTP WML Decks with WML-Script WMLScript Compiler WTAI Protocol Adapters Content Etc. Mobile Payments(WAP Gap) • Wireless Gateways as a Single Point of Failure

  30. Mobile Payments(Problems) • WML Script Problems • Does not differentiate trusted local code from untrusted code downloaded from the Internet. So, there is no access control!! • WML Script is not type-safe. • Scripts can be scheduled to be pushed to the client device without the user’s knowledge • Does not prevent access to persistent storage • Possible attacks: • Theft or damage of personal information • Abusing user’s authentication information • Maliciously offloading money saved on smart cards

  31. Mobile Payments(Example) • Paybox

  32. Mobile Payments(Example) • Paybox security concerns • Payer must render to payee mobile phone Id or Paybox pseudonym • Payer uses PIN authentication and authorization • Payments neither non-repudiable nor durable • Risk for merchant and Paybox operator

  33. E-cashProviding Flexible Anonymity • Australia Queensland University • A recent work – March 2005 • “A Flexible Payment Scheme and its Role-based Access Control” • Lack of flexibility of anonymity • Online payment systems • Require Banks to validate on purchase • Keeping a database of all spent coins • Offline payment systems • Cryptographic verification of payment • Suffer from double spending

  34. E-cashProviding Flexible Anonymity • RBAC (Role-Based Access Control) • Different privileges for different services • Privileges in terms of job functions • Low administration cost and complexity • Little research on RBAC in payment scheme management

  35. Preliminary Concepts • DLA and ElGamal Encryption • Discrete logarithm problem • y = gx, element g in group G of order q, 0<x<q-1 • Generator element can generate all elements of G by exponentiation • El Gamal Public Key Encryption

  36. New Payment Model • Offline: Shop does not communicate with bank during payment • Untraceable: Can not identify coin’s origin • Anonymous: Bank and shop can not trace the coin to the consumer • Double spending in absence of tamper-proof hardware. Not possible to check with online databases in an offline system

  37. New Payment Model • Setup phase • Bank, shop, consumer • Account openings, key generations • Anonymity Provider (AP) agent helps to provide anonymity • Not involved in purchase process • Issues a certificate to the user

  38. New Payment Model • Anonymity Provider Agent • Coin c = f(pkB,pku,y) and Certc • New Certc’ after AP process • Coin c’ = f(pkB,pku,y+v) • Consumer provides undeniable signature S and the equivalance of c and c’ • Consumer confirms the validity of S • AP agent certifies new coin c’ • AP agent is a notarized participant

  39. New Payment Model • Proof of Ownership of a coin • I=gxu • Coin c=(a=gr,b=YrIs), r and s are random • Certificate of the bank assures that coin is valid • Consumer has to convince his knowledge of (xu,r,s) such that b=YrIs

  40. New Payment Model • Proof of validity of a coin

  41. Anonymity Scalable Payment • System Initialization • Bank Setup • Primes p and q are chosen • Generator g of unique subgroup Gq with prime order q • p of multiplicative group Zp • Secret key xB created • Bank publishes p,q,g,H and Y=gXB(mod p) • Secret key is safe under DLA • Consumer Setup • Bank associates customer with I = gXu(mod p) • Shop setup similar to consumer setup • Accounts are opened

  42. Anonymity Scalable Payment • New Offline Payment Scheme • Withdrawal • Coin is an encryption of consumer’s public key using the public key of bank • Consumer constructs c=(a=gr,b=YrIs) • Schnorr signature S on the message c combined with date etc. • (c,S) sent to bank together with r and I • Bank checks signature and sends Certc • Consumer needs to remember (r,s,Certc)

  43. Anonymity Scalable Payment • Anonymity Scalability • I and Certc known by bank • Consumer can derive a new encryption of his identity • Needs a new certificate for the new encryption

  44. Anonymity Scalable Payment • Anonymity Scalability • Consumer contacts AP agent, chooses randomp • c’ = (a’ = gpa, b’=Ypb) • Consumer generated Schnorr signature S on m=hp • Can not deny knowledge of p later • Consumer provides proof of equivalence • loghm=logg(a’/a)=logY(b’/b) • Consumer sends c,c’,S and m to AP agent • AP agent checks Certc on c and the signature on m then certifies c’ with Certc’ • New encryption is strongly anonymous from the point of view of bank • AP agent needs to store (c,c’,m,S)

  45. Anonymity Scalable Payment • Payment • Spending by proving knowledge of secret key (xu,s) associated with coin c or c’ • Deposit • Shop sends payment transcript to the bank later • Transcript contains the coin,signature and time of transaction • Bank verifies correctness and credits the coin into shop’s account • If double spending occurs then same coin will be received by bank • Two different signatures • Bank can isolate consumer and trace payment to I

  46. Security Analysis • An offline e-cash scheme is secure if • Unreusable • If the same coin is used twice, identity of user can be found • Untraceable • No one can trace a consumer from the cash used • Unforgeable • No one can compute valid coins • Unexpandable • The identity of the user can not be computed

  47. Security Analysis • Unreusable • Recall : S = (e,u,v,t1) • If consumer uses same coin twice • S1 = (e1,u1,v1,t1) and S2 = (e2,u2,v2,t2) • v1 = s – xue1 and v2 = s – xue2 • Then, (v2 – v1)/(e1 – e2) = xu which is the private key

  48. Security Analysis • Untraceable • Consumer uses secret keys xu and s, which are never revealed to anyone • Unforgeable • Steps to produce a valid coin • Make an encryption of the coin • Sign an undeniable signature using xu • Bank and AP agent can not forge a coin • They do not know xu • Unexpandable • xu and s are never revealed • s is different for different coins

  49. RBAC Management • Duty Separation Constraints • Define mutual exclusive roles or constraints on roles that can be taken • SSD (Static separation of duty) : fixed separation of duties before runtime • DSD (Dynamic separation of duty) : dynamic separation of duties during runtime

  50. RBAC Management • Duty Separation Constraints