Payment Authentication and Mobile Payment Systems

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