1.

Amendments to Interoperability Standards for Mobile Payments

2. Discussion paper on Security for Mobile payments

Dr Gaurav Raina Department of Electrical Engineering IIT Madras E-mail: gaurav@ee.iitm.ac.in

Challenges for Mobile Payments

Interoperability Security
Universality Usability Privacy Trust Cost Performance

Cross-border payments

Interoperability Standards V1.10

TSP Telecommunication Service Provider

MPP Mobile Payment Provider

Interoperability Standards V1.A

Customer
Customer

MPP

Beneficiarys mobile number, MMID, Amount

MPP

Bank

Central Switch/ settlement agency

Bank

Core Banking System (CBS)

Each mobile number will be linked to a bank account

Core Banking System (CBS)

MMID

Mobile Money Identifier

Was uploaded to MPFI website: 29 Nov, 2010 Request for comments by 15 Dec, 2010

MMID (Mobile Money IDentifier)

Allows Multiple Accounts Safety-net in case mobile number entered incorrectly Allows routing of transactions

Cf. Procedural Guidelines for IMPS, NPCI, page 5, June 2010

Phase 1 7 digit MMID Phase 2 3 digit MMID (with central repository)

Discussion paper on Security for Mobile payments

Background

Interoperability Standards for Mobile Payments Technology Sub-Committee for Mobile Payments Security

Discussion Paper on Mobile Payment Security, 7th Feb 2011 Discussion Paper to eventually turn into a Standards Document
Institutions part of the Technology Sub-Committee
Tata Teleservices Ltd IDRBT mCheck Comviva Technologies Ltd ICICI Bank IIT Madras

Objectives and scope of Discussion Paper

To undertake an assessment of the key security concerns for mobile payments Identify the threats and vulnerabilities for mobile payments Recommendations for minimizing/eliminating the identified threats

Identify the main security breach points (1) Mobile device level (2) Application level (3) Channel level Then consider each of the breach points from the perspective of (1) Technology (2) Interoperability Standards (3) Operative guidelines set out by the RBI

RBI Security Guidelines

Authentication banks providing mobile banking services shall comply with the following security principles and practices for the Authentication of mobile banking transactions:

A. All mobile banking shall be permitted only by validation through a two factor authentication.
B. One of the factors of authentication shall be mPIN, or any other higher standard. C. Where mPIN is used, end-to-end encryption of the mPIN is desirable; i.e. mPIN shall not be in clear text anywhere in the network. D. The mPIN shall be stored in a secure environment.

Interoperability
Customer
Customer

MPP

Beneficiarys mobile number, MMID, Amount

MPP

Bank

Central Switch/ settlement agency

Bank

Core Banking System (CBS)

Each mobile number will be linked to a bank account

Core Banking System (CBS)

Interfaces in a Transaction flow

Wireless Interface

Customer-to-MPP

Wired Interfaces

MPP-to-Bank Bank-to-CBS Bank-to-Bank

Customer MPP Interface

Mobile payments using

Case 1. bearer services Case 2. mobile browsing services Case 4. SIM application toolkit

(SMS, USSD, IVR) (HTTPS, WAP) (STK)

Case 3. advanced application services (J2ME)

Template for evaluating all technologies

Capability of the phone

Positive features Compliance with RBI guidelines

Other aspects
Key concerns Key recommendations

Customers Banks Etc.

IVR

BTS BSC HLR MPP

Base Transceiver Station Base Station Controller Home Location Registry Mobile Payment Provider

SMSC SMS Message Switching Centre

IVR

Capability of the phone

All Handsets

Positive Features

Different levels of literacy Very secure with voice biometrics Easy to use Cost per transaction is low

Compliance with RBI guidelines

Yes, with voice biometrics

Other aspects

Voice biometrics not standardized

Different implementations / solutions could have different performance

Interact through the use of voice & DTMF keypad inputs

IVR
key concerns / recommendations

If DTMF tones used to transfer information possibility of tapping and deciphering confidential data

Recommended to use voice biometrics

Security of database / transaction logs where confidential information may be stored, either by design or inadvertently

Security audits can eliminate this concern Voice biometrics or other authentication data should be stored in encrypted form

For concerns over called ID and replay attacks, liveness test should be used.

Sub working groups

SMS and USSD

Comviva and Eko Comviva, Voxta, Uniphore Paladion Networks and RS Software

IVR

Mobile browsing services

Advanced application services (J2ME)

Comviva, Paladion Networks, RS Software and Voxta

Syscom

Sim application ToolKit (STK)

Emerging Technologies (NFC)

Samsung

Other relevant documents

1. Working Group on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds. Report and Recommendations, Reserve Bank of India, Jan 2011 2. Amended IT Act 2008 Request for someone in MPFI who has a strong technological and legal understanding to work with the TSC to assess the relevance of the recommendations in the context of the Amended IT Act, and vice versa.

Example, recommended to adopt Wireless PKI.

Q: Does this meet the reliability criteria as given in the Amended IT Act, 2008? If yes, the MPFI can recommend Department of Information Technology to include WPKI legality while framing and notifying rules for Electronic Signature.

Summary

Next Steps

Develop a thorough, in depth, understanding of all technologies with respect to security and end-to-end performance

Review all recommendations in the context of the Amended IT Act, 2008

Work towards a Standards Document

IVR key recommendations

Customer

Do not store any confidential messages/information on the phone Delete the already sent mobile payment messages that contain sensitive information

Banks

Imposing threshold on the amount of transaction based on the risk perspective Educating the customers on best practices of Mobile payments security

SMS

Capability of the phone

Available in all handsets today

Positive feature

Most used data application in the world

Compliance with RBI Guidelines

Not end to end secure

Other aspects

PIN is usually requested through USSD Payment through SMS SMS are also available for encryption

<Function code, MMID, Beneficiary mobile number, amount>

USSD

Capability of the phone

Not supported in CDMA handsets

Positive feature

Session based communication

Compliance with RBI guidelines

Not end to end secure But, less prone to spoofing and hacking compared to SMS

Other aspects

Information sent in clear text Security solely depends on GSM channel

Case 1. bearer services (SMS, USSD, IVR)

key concerns
Mobile Device Level

SMS's being sent & received are automatically saved USSD session with AT commands

Channel Level

Security might be compromised in

Telecom Switching network Database level

Real Threat lies in Transaction logs

Weak Encryption
Unilateral Authentication Over-The-Air cracking SMS spoofing

Case 1. bearer services (SMS, USSD, IVR) key recommendations

Customer

Donot store any confidential messages/information on the phone Delete the already sent mobile payment messages that contain sensitive information

Banks

Imposing threshold on the amount of transaction based on the risk perspective Educating the customers on best practices of Mobile payments security

Case 2. mobile browsing services (HTTPS, WAP)

BTS BSC HLR MPP SMSC

Base Transceiver Station Base Station Controller Home Location Registry Mobile Payment Provider SMS Message Switching Centre

Wireless Application Protocol (WAP)

Capability of the phone

Only in advanced handsets

Positive feature

Open standard for application layer network communications

Compliance with RBI guidelines

End to end security possible

Other aspects

WAP browser access the websites written in WML WAP based applications use GPRS as the data transport layer and is secured either by

Encryption provided by GPRS Wireless Transport Layer Security (WTLS)

Case 2. mobile browsing services (HTTPS, WAP) key concerns

Mobile Device Level

Restricted Key size

mPIN might get stored inadvertently in the browser

Virus, Malware, Cookies

Channel Level

WAP Gateway

WTLS isn't supported by all WAP gateways

Case 2. mobile browsing services (HTTPS, WAP) Key recommendations

Customer

Ensuring mobile handset free from virus by having an up to date Anti-virus

Bank

Smaller key size usage in Wireless Transport Layer Security (WTLS) needs to be analyzed Disable the automatic storage of mPIN in the browser for the mobile payment application

Timestamps/One-time-password can be used to counter replay attacks

Case 3. advanced application services (J2ME)

BTS BSC HLR MPP SMSC

Base Transceiver Station Base Station Controller Home Location Registry Mobile Payment Provider SMS Message Switching Centre

Mobile payment application: in phone memory

Capability of the phone

Today, most handsets support Java (J2ME)

Positive feature

Easy to use, menu driven

Compliance with RBI guidelines

End to end security possible

Other aspects

Applications in Java (J2ME) for GSM handsets, BREW for CDMA Storage of clients credentials

Inside the SIM

RMS (record management system)

Case 3. advanced application services (J2ME) key concerns

Mobile Device Level

Information stored in Record Management System (RMS) can be read easily Random numbers used in key generation can be guessed by an alert hacker Authentication check if performed by the client side application poses a serious threat

Channel Level

Case 3. advanced application services (J2ME)

key recommendations
Bank

Store the sensitive information in an encrypted format

Symmetric key encryption can be used if shared key can be stored in a secure environment Hybrid Protocols like SSL (Employs both Symmetric & Asymmetric key Encryption) is preferred Authenticity check should be performed at the server side Timestamps/One-time-password can be used to counter replay attacks

Case 4. SIM application toolkit (STK)

BTS BSC HLR MPP SMSC

Base Transceiver Station Base Station Controller Home Location Registry Mobile Payment Provider SMS Message Switching Centre

Mobile payment application: embedded in the SIM

Capability of the phone

Can be implemented in all handsets

Positive feature

Easy to use, no need to install application

Compliance with RBI guidelines

End to end secure

Other aspects

Information in SIM is protected using crypto algorithms & keys

Applications developed using SIM Application Toolkit (SAT) & JavaCard

Application can be stamped either in

Manufacturing phase or Dynamically installed through Over The Air

Case 4. SIM application toolkit (STK)

key concerns
Mobile Device Level

Downloading of Applets is a time consuming process

Slowness of the Key generation & Signature process

Generated signatures may not be qualified

Mobile malware like keylogging trojan

Case 4. SIM application toolkit (STK)

key recommendations
Customer

Ensuring mobile handset free from virus by having an up to date Anti-virus

Bank

Use Symmetric Encryption and store the key inside a SIM in an encrypted format Adopt Wireless Public Key Infrastructure (WPKI)

Telecommunication Service Provider (TSP)

Increase the processing abilities a SIM card

Summary

Bearer Services (SMS, USSD, IVR)

Usability: Easy to use, available on all handsets

Security: Not end-to-end secure, transaction limits should be set

Mobile browsing services (WAP)

Usability: (not so) easy to use, but requires GPRS

Security: End-to-end security possible

Advanced application services (J2ME)

Usability: Easy to use, most handsets support Java (J2ME)

Security: End-to-end security possible

SIM Application Toolkit (SAT)

Usability: Very easy to use as part of the menu

Security: Most secure solution, but requires change in SIM

Some recent references

Working Group on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds. Report and Recommendations, Reserve Bank of India, Jan 2011

Securing Mobile Payments: Modelling, Design, and Analysis by Supakorn Kungpisdan, Lambert Academic Publishing, 2010