Payment Authentication and Mobile Payment Systems

1
Payment Authentication and Mobile Payment Systems

• Cmpe 526
• Operating System and Network Security
• Erdem Savas Ilhan

Spring 2005 Bogaziç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
• Merchants bank checks with issuer for payment
  authorization
• Issuer sends authorization to merchants bank
• Merchants 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 CAs 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 merchants 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 merchants 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 Merchants
  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
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 users knowledge
• Does not prevent access to persistent storage
• Possible attacks
• Theft or damage of personal information
• Abusing users 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
• 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 coins 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,yv)
• 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
• Igxu
• Coin c(agr,bYrIs), 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 bYrIs

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 YgXB(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 consumers public key
  using the public key of bank
• Consumer constructs c(agr,bYrIs)
• 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, bYpb)
• Consumer generated Schnorr signature S on mhp
• Can not deny knowledge of p later
• Consumer provides proof of equivalence
• loghmlogg(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 shops 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

51
RBAC Management

• Four major roles
• AP agent
• Consumer
• Bank
• Shop
• AP agent, shop and bank have a DSD relationship
  with consumer
• Cannot act these roles simultaneously

52
RBAC Management

• AP agent has an SDD relationship with the bank
• Otherwise the anonymity is compromised
• Bank has an SSD relationship with the shop
• Bank verifies payment and deposits the money into
  shops account

53
Scenarios of End Users

• End users must choose an active role set from the
  roles assigned
• Should not violate constraints
• Once the choice is made a session is established
  with the roles selected

54
Conclusions

• 3D Secure approach promises user authentication
• Mobile payments lack standardization
• E-cash systems needs extensive cryptographic
  operations and scalable architecture