payment authentication and mobile payment systems l.
Download
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...

play fullscreen
1 / 54

Payment Authentication and Mobile Payment Systems - PowerPoint PPT Presentation


  • 1059 Views
  • Uploaded on

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. Outline. Introduction Security of Electronic Payments SET Recent Authentication Practices

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Payment Authentication and Mobile Payment Systems' - Solomon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
payment authentication and mobile payment systems

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

outline
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
introduction
Introduction
  • Electronic Payment
    • Credit
    • Cheque
    • Cash
introduction4
Introduction
  • Payment information should be secured
    • Authentication
    • Authorization
    • Confidentiality
    • Non-repudiation
    • Privacy
    • Anonymity
set protocol purpose
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
set protocol overview
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
set protocol properties
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
set protocol verification
SET Protocol(Verification)
  • Merchant verifying purchase request
set protocol
SET Protocol
  • Dual Signatures
    • Merchant sends authorization request to acquirer
      • Payment instructions + order message digest
set protocol process in detail
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
set protocol11
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
set protocol12
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
set protocol13
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
set protocol problems
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
3d secure purpose
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
3d secure overview
3D Secure(Overview)
  • Purchase transaction
3d secure overview17
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.
3d secure issuer
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
3d secure merchant acquirer
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
3d secure interoperability visa
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
3d secure global authentication network
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

3d secure user authentication
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
3d secure conclusion
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
mobile payments introduction
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)
mobile payments technologies
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
mobile payment technologies
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
mobile payments technologies28
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
mobile payments wap gap

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
mobile payments problems
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
mobile payments example32
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
e cash providing flexible anonymity
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
e cash providing flexible anonymity34
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
preliminary concepts
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
new payment model
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

new payment model37
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
new payment model38
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
new payment model39
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
new payment model40
New Payment Model
  • Proof of validity of a coin
anonymity scalable payment
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
anonymity scalable payment42
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)
anonymity scalable payment43
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
anonymity scalable payment44
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)
anonymity scalable payment45
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
security analysis
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
security analysis47
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
security analysis48
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
rbac management
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
rbac management50
RBAC Management
  • Duty Separation Constraints
rbac management51
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
rbac management52
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 shop’s account
scenarios of end users
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
conclusions
Conclusions
  • 3D Secure approach promises user authentication
  • Mobile payments lack standardization
  • E-cash systems needs extensive cryptographic operations and scalable architecture