• No results found

Security Requirement of Mobile Application Based Mobile Payment System

N/A
N/A
Protected

Academic year: 2021

Share "Security Requirement of Mobile Application Based Mobile Payment System"

Copied!
5
0
0

Loading.... (view fulltext now)

Full text

(1)

Mobile Payment System

Hyun-Jung Lee and Dongho Won Information Security Group,

School of Information and Communication Engineering, Sungkyunkwan University, 300 Cheoncheon-dong, Jangan-gu,

Suwon, Gyeonggi-do 440-746, Korea {hjlee, dhwon}@security.re.kr

Abstract. Once a method of payment has achieved widespread use, it will be-come the target of hackers and thieves. Consider the security dilemmas associ-ated with one of the most popular methods of payment: credit cards. With all the security gaps inherent in credit cards, a mobile platform is even more vul-nerable still. Because a mobile platform has the added vulnerability of being a ―mini-computer‖, it can be targeted using techniques that are much less obvious than those associated with credit cards. This paper intends to derive necessary security functions of a Mobile App-Based Mobile Payment System based on the Common Criteria V3.1.

Keywords: Mobile Payment System, Mobile Device, Protection Profile, Com-mon Criteria, Security Requirement

1

Introduction

The mobile payment system eliminates the inconvenience of possessing a large number of cards using the mobile device. Therefore it is expected that more banks and credit card companies will construct mobile payment system in the future.

Due to the widespread availability of mobile phones and their extensive usage worldwide, it is a reasonable expectation that payment schemes involving a mobile phone will soon be a dominate force in electronic payments. At the same time, vul-nerabilities in secure financial transactions can severely compromise the implementa-tion and future success of mobile payment systems.

This paper is organized as follows: Section 2 analyzes the operation of the Mobile Application based Mobile Payment System. Section 3 identifies threats. Section 4 describes security objectives of Mobile Application based Mobile Payment System. Section 5 proposes security requirements of a Mobile Application based Mobile Pay-ment System which applies a methodology based on CC V3.1. And lastly, Section 6 presents the conclusion.

(2)

2

Mobile Payment System

Mobile payment is defined as: Payment for products or services between two par-ties for which a mobile device, such as a mobile phone, plays a key role in the realiza-tion of the payment[5]. Mobile payments can be categorized based on the technology used as either one of two types—proximity or remote[5].

This paper proposes the threat, security object and security requirement about Mo-bile application based moMo-bile payment system (MPS) of all remote moMo-bile Payment way. MPS is a way to perform a payment using the Authentication information and Card account information stored in the mobile application. Mobile device security is very important because mobile device store the user's card information, banking in-formation, authentication inin-formation, etc. In Addition, We must consider problem that the loss and deodorization of mobile device arise in.

3

Threats

This subsection of the security problem definition shows the threats that are to be countered by the MPS. A threat consist of a threat agent, an asset and an adverse ac-tion of that threat agent on that asset[1,2,3]. The specificaac-tion of threats should in-clude all threats detected up to now[4,5,6,7,8,9,10,11,12], if it is not done the MPS may provide inadequate protection. In other words, if the specification of threats is insufficiency, the assets may be exposed to an unacceptable level of risk. The Threats for this paper are described in Table I.

Table 1. Threat

Mobile App Threat

T.Unauthorized User

The threat agent disguised as a legitimate user, and electronic financial transactions can be performed.

T.Guessing(1) Authentication information can be inferred by using the feedback infor-mation of the authentication process. T.Intercept Mobile Authentication data is intercepted when entered into a mobile device. T.Leakage The threat agents can seize the important information (such as authentica-tion information, card information) is stored in the Mobile device. T.Guessing(2) The threat agent can be inferred authentication information through the exhaustive attack about authentication information. T.disguise The and can seize the user's authentication information and card information. threat agents disguised as financial institutions T.Rooting ―Root‖ or ―jail-break‖ makes the mobile device insecurely.

T.Malware Threat can infect the mobile application with malware or unauthorized application. T.Hijacking Threats intercept traffic (e.g. account data) over the air (OTA) transmitted between phone and Service Provider. T.Modify The threat agent modifies the financial transactions data And transmits the modified data to the Service Provider. T.Stored Data The threat agents can forge electronic financial transactions data that stored in the financial institutions. T.Denail You cannot deny the fact that the electronic financial transactions.

(3)

4

Proposed Security Objective

Security objectives are concise, abstract statements of the intended solution to the problem defined by the security problem definition. The set of security objectives for a MPS form a high-level solution to the security problem. This section identifies the security objectives for the MPS.

Table 2.Security Objective

Security Objectives Description

O.IA Before executing the payment, PSP should clearly authenticate and identify the mobile payment user. O.FeedBack

Protec-tion Must not be able to guess the authentication information through Authentication failure handling mechanism. O.Data Protect Prevent Confidential data (e.g. account data, card data) from com-promise while processed or stored within the mobile device.

O.OTP To be Safe from exhaustive attack Should provide a means to generate a different password authentication with dynamic characteristics each time. O.Restrict Must limit the number of authentication failure.

O.Auth Mobile Application has to confirm that PSP are legitimate.

O.Detect Rooting Provide the capability for the device to produce an alarm or warning if there is an attempt to ―root‖ or ―jail-break‖ the device;

O.SecureStatus Keep a secure status for protecting mobile payment applica-tion.(delete the malware and unauthorized application) T.Secure

Communi-cation

Prevent account data from interception upon transmission out of the mobile device.

O.Integrity(1) The PSP should be able to determine whether the modification and forgery of electronic financial transactions.

O.Integrity(2) PSP should protect the saved data (electronic financial transaction data) from unauthorized exposure, alteration and removal.

O.Non-repudiation The PSP should provide a means that cannot deny the fact that a legitimate electronic financial transaction.

O.Audit A process should exist for the detection and reporting of the theft or loss of the mobile device.

5

Security Functional Requirements

The Security functional requirements substantiate the security objectives. Each se-curity functional requirement must be related to one or more sese-curity objectives. The-se requirements are defined in CC part 2, and protection profile author just chooThe-ses and uses appropriate requirements. The security functional requirements for this paper are described in Table III[1,2,3].

(4)

Table 3.Security Functional Requirements

Functional class Functional component

Security audit (FAU) FAU_ARP.1, FAU_SAR.1, FAU_STG.1, FAU_STG.3, FAU_STG.4 FAU_GEN.1, FAU_GEN.2, FAU_SAA.1,

Communication(FCO) FCO_NRO.2, FCO_NRR.2

Cryptographic support(FCS) FCS_CKM.1, FCS_COP.1 FCS_CKM.2, FCS_CKM.3, FCS_CKM.4,

User data protection (FDP) FDP_ACC.2, FDP_RIP.2, FDP_SDI.2 FDP_ACF.1, FDP_MDD_EXT.1, FDP_ITT.1,

Identification and authentication (FIA)

FIA_AFL.1, FIA_ATD.1, FIA_SOS.1, FIA_UAU.2, FIA_UAU.3, FIA_UAU.4, FIA_UAU.7, FIA_UID.2

Security management (FMT)

FMT_MOF.1, FMT_MSA.1, FMT_MSA.2, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1

Protection of the TSF(FPT) FPT_ITT.1, FPT_TST.1 Anti-Malware(FAM) FAM_DTM_EXT.1

6

Conclusions

This paper proposed security requirements which can be used as a request for a proposal to procure an mobile Payment system, a guideline for developers a secure Mobile Payment system and criteria with evaluators can evaluate the completeness of a developed system. Thus, the Mobile Payment System was analyzed, a threat was modeled, and CC based security requirements were deduced. Moreover, the threat model and security requirements presented in this document can be applied to mobile cloud service environments.

Reference

1. Common Criteria, Common Criteria for Information Technology Security Evaluation; part 1: Introduction and general model, Version 3.1 R1, CCMB-2006-09-001(September 2006) 2. Common Criteria, Common Criteria for Information Technology Security Evaluation; part

2: Security functional components, Version 3.1 R2, CCMB-2007-09-002(September 2007) 3. Common Criteria, Common Criteria for Information Technology Security Evaluation; part 3: Security assurance components, Version 3.1 R2, CCMB-2007-09-003(September 2007) 4. Prabu Raju, Anil Gajwani , Prof. T.A. Gonsalves , Ch.Raja: Analysis of Mobile

Infrastruc-ture for Secure Mobile Payments, Mobile Payment Forum, India – March 2008

5. Ashok Goudar, Mobile Transections and Payment Processing White Paper, MPHASIS an HP Company

6. Security Requirements for Mobile Operating Systems V1.0, Information Assurance Direc-torate, 2013.1.25

7. PCI Mobile Payment Acceptance Security Guidelines V1.0, Emerging Technologies PCI security Standards Council, 2012.9

(5)

9. CollinMulliner, Vulnerability Analysis and Attacks on NFC-enabled Mobile Phones, 2009 International Conference on Availability, Reliability and Security

10. VISA, Visa Security Best Practices for Mobile Payment Acceptance Solutions, Version 2.0, 2012.6.13

11. Yan Liu, Security Proposal on mobile Payment , 13ICCC(2013.9) 12. ISACA, Mobile Paymnet:Risk, Security and Assurance Issues, 2011.11

Figure

Table 1. Threat
Table 2. Security Objective
Table 3. Security Functional Requirements

References

Related documents

Bubble size corre- sponds to the relative abundance of bacterial OTUs detected in each aphid species, excluding the primary symbionts (see Supporting Information Fig. S1 and Appendix

A wooden cylinder of diameter 4r, height H and density /3 is kept on a hole of diamete 2r of a tank, filled with liquid of density  as shown in the figure. If level of the liquid

There are many Pokemon where the girl version is easier to find (lik e Jigglypuff), so you might want to use this code to fnid a

In the context of this document a Mobile Contactless Payment (MCP) is any SEPA Card based payment executed by a Customer using a dedicated Mobile Contactless Payment

On the basis of solutions, global mobile security market is segmented into authentication, mobile application management and mobile data protection.. The mobile application

Data, Network & Access Security App/Test Development Mobile Device Management Mobile Device Management Acquire/Deploy Secure Mobile Application Mobile Device Security

During 2007 – 2008 the Ministry of Fisheries Wealth (MFW) Sultanate of Oman conducted a survey to provide estimates of the fishable biomass of principal demersal, small pelagic

UNIVERSIDAD DE MANILA (CITY