Criteria Requirements of Mobile Payment Application

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014), pp.79-88 http://dx.doi.org/10.14257/jse.2014.02.11 Criteria Requirements of Mobile Payment Application Hyun-Jung Lee 1), Jae-In Shin 2), Kab-Seung Kou 3), Chan-Ho, Ryu 4) Abstract Diffusion of smart phone has brought about various changes in social culture, finance or distribution industry as mobile phone is evolved from simple device which is just used for communication into useful device which include many functions for communication, distribution, internet or payment. Especially in the payment and settlement, diffusion of mobile payment method by smart phone causes new changes of the means of payment which has been changed cash to plastic card. In this paper, treats in mobile payment methods of smart phone based on Common Criteria V3.1 are analyzed and as the analysis, we define the security requirements in mobile payment methods. Keywords : Mobile Payment Application, Smart Phone, Protection Profile, Common 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. By Building the combined electronic Payment system that include the various payment methods and using the accumulated transaction data, we expect to be able to take advantage by to create new value-added. In the end, the banks and credit card companies, is expected to continue to respond in such a way that joining forces with mobile payment providers, or building themselves competing systems. Juniper Research forecasts that the mobile payment market will increase from $ 2,400 billion in 2011 to $ 6,700 billion in 2015. And, Gartner forecasts that worldwide mobile payment users increase about 70% from to last year's 43.1 million people to 73.4 million people a year and the mobile payment industry is expected to Received(December 29, 2013), Review request(december 30, 2013), Review Result(1st: January 09, 2014, 2nd: February 22, 2014) Accepted(February 28, 2014) 1 138-200 TA Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: hjlee@kosyas.com 2 138-200 R&D Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: jaein@kosyas.com 3 138-200 R&D Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: kabseung@kosyas.com 4 (Corresponding Author)138-200 Consulting Team, Korea System Assurance, Munjeong-dong, Songpa-gu, Seoul, Korea email: chryu@kosyas.com * This research was funded by the MSIP(Ministry of Science, ICT & Future Planning), Korea in the ICT R&D Program 2013 ISSN: 1738-7531 JSE 79 Copyright c 2013 SERSC

Criteria Requirements of Mobile Payment Application show steady growth. 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, vulnerabilities in secure financial transactions can severely compromise the implementation and future success of mobile payment systems[5, 6, 7, 8, 9, 10, 11 and 12]. 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 Payment System which applies a methodology based on CC V3.1. And lastly, Section 6 presents the conclusion. 2. Mobile Payment Application Mobile payment is defined as: Payment for products or services between two parties for which a mobile device, such as a mobile phone, plays a key role in the realization of the payment[2]. Mobile payments can be categorized based on the technology used as either one of two types proximity or remote. Proximity Mobile Payment: Proximity mobile payment generally refers to contactless payments in which the payment credential is stored in the mobile device and is exchanged over the air, based on NFC technology, with a dedicated and compatible payment terminal. In other words, the mobile device acts as a contactless payment card, thus becoming a new payment form factor. Remote Mobile Payment: Remote mobile payment covers payments that take place either via a mobile web browser or a resident smartphone application, in which the mobile phone is used as a device to authenticate personal information stored remotely. Remote payment solutions also can be used for transactions such as face-to-face and vending machine transactions. This paper proposes the threat, security object and security requirement about mobile application based mobile payment of all remote mobile Payment way. Mobile Application based Mobile Payment 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 information, authentication information, etc. In Addition, We must consider problem that the loss and deodorization of mobile device arise in. 80 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) [Fig. 1] Mobile App-Based Mobile Payment System s Architecture Operation among the above three components is executed in eight Steps. 0. (Mobile User Registration) Mobile user installs the mobile payment application on mobile device and register mobile payment service of mobile Payment Service Provider. 1. (Product Purchase) Users purchase the contents or product from on-line merchant (Content Provider). a. Select Payment Method : mobile application Payment b. The user s payment details are passed to the respective payment service provider (through mobile transaction service provider), for payment authorization and subsequent settlement (payment is authorized against users account held in the issuer bank). 2. CP requests the billing to PSP. 3. PSP asks for a confirmation to the user about the fact that the payment request. 4. After verification of the bills, users perform checkout operation. 5. (Authentication) User present the Authentication data with either a payment screen. If the authentication is successful, PSP, requested payment information to the user. 6. Users pass the card and payment information registered on mobile Payment application on to the PSP. 7. After PSP verify the payment data, process the payment. a. The user s payment details along with card details are passed to the respective payment service provider (through mobile transaction service provider), for payment authorization and subsequent settlement (payment is authorized against users account held in the issuer bank). 8. PSP notify the result of the payment to mobile user and Content Provider. Copyright c 2014 SERSC 81

Criteria Requirements of Mobile Payment Application 3. Threats This subsection of the security problem definition shows the threats that are to be countered by the Mobile Payment System. A threat consist of a threat agent, an asset and an adverse action of that threat agent on that asset[1]. The specification of threats should include all threats detected up to now[3 and 4], if it is not done the Mobile Payment System 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 1]. [Table 1] Mobile Payment System threats Mobile App Communication Channel Service Provider Threat T.Unauthorized User T.Guessing(1) T.Intercept T.Leakage T.Guessing(2) T.disguise T.Rooting T.Malware T.Hijacking T.Modify T.Stored Data T.Denail Description The threat agent disguised as a legitimate user, and electronic financial transactions can be performed. Authentication information can be inferred by using the feedback information of the authentication process. Mobile Authentication data is intercepted when entered into a mobile device. The threat agents can seize the important information (such as authentication information, card information) is stored in the Mobile device. The threat agent can be inferred authentication information through the exhaustive attack about authentication information. The threat agents disguised as financial institutions and can seize the user's authentication information and card information. Root or jail-break makes the mobile device insecurely. Threat can infect the mobile application with malware or unauthorized application. Threats intercept traffic (e.g. account data) over the air (OTA) transmitted between phone and Service Provider. The threat agent modifies the financial transactions data And transmits the modified data to the Service Provider. The threat agents can forge electronic financial transactions data that stored in the financial institutions. You cannot deny the fact that the electronic financial transactions. 4. Proposed Security Objective and Security Requirements 4.1 Security Objectives Security objectives are concise, abstract statements of the intended solution to the problem defined by the 82 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) security problem definition. The set of security objectives for a Mobile Payment System form a high-level solution to the security problem. [Table 2] identifies the security objectives for the Mobile Payment System. [Table 2] Mobile Payment System security objectives Security Objectives O.IA O.FeedBack Protection O.Data Protect O.OTP O.Restrict O.Auth O.Detect Rooting O.SecureStatus T.Secure Communication O.Integrity(1) O.Integrity(2) O.Non-repudiation O.Audit Description Before executing the payment, PSP should clearly authenticate and identify the mobile payment user. Must not be able to guess the authentication information through Authentication failure handling mechanism. Prevent Confidential data (e.g. account data, card data) from compromise while processed or stored within the mobile device. To be Safe from exhaustive attack Should provide a means to generate a different password authentication with dynamic characteristics each time. Must limit the number of authentication failure. Mobile Application has to confirm that PSP are legitimate. Provide the capability for the device to produce an alarm or warning if there is an attempt to root or jail-break the device; Keep a secure status for protecting mobile payment application.(delete the malware and unauthorized application) Prevent account data from interception upon transmission out of the mobile device. The PSP should be able to determine whether the modification and forgery of electronic financial transactions. PSP should protect the saved data (electronic financial transaction data) from unauthorized exposure, alteration and removal. The PSP should provide a means that cannot deny the fact that a legitimate electronic financial transaction. A process should exist for the detection and reporting of the theft or loss of the mobile device. 4.2 Security objectives for the operational environment The operational environment of the Mobile Payment System implements technical and procedural measures to assist the Mobile Payment System in correctly providing its security functionality (which is defined by the security objectives for the Mobile Payment System). This part wise solution is called the security objectives for the operational environment and consists of a set of statements describing the goals that the operational environment should achieve. The operational environments of the TOE for this paper are described in [Table 3]. Copyright c 2014 SERSC 83

Criteria Requirements of Mobile Payment Application [Table 3] The operational environments of the TOE Security Objectives OE.SecureLock OE.Update Description To prevent unauthorized access to mobile device, Need to enable the secure lock Screens that are provided by the OS. Mobile device security updates are performed on a regular basis. 5. Security Functional Requirements 5.1 Security Functional Requirements The Security functional requirements substantiate the security objectives. Each security functional requirement must be related to one or more security objectives. These requirements are defined in CC part 2, and protection profile author just chooses and uses appropriate requirements. The security functional requirements for this paper are described in [Table 4]. [Table 4] The security functional requirements Functional class Security audit (FAU) Communication (FCO) Cryptographic support (FCS) User data protection (FDP) FAU_ARP.1 FAU_GEN.1 FAU_GEN.2 FAU_SAA.1 FAU_SAR.1 FAU_STG.1 FAU_STG.3 FAU_STG.4 FCO_NRO.2 FCO_NRR.2 FCS_CKM.1 FCS_CKM.2 FCS_CKM.3 FCS_CKM.4 FCS_COP.1 FDP_ACC.2 FDP_ACF.1 FDP_MDD_EXT.1 FDP_ITT.1 FDP_RIP.2 FDP_SDI.2 Functional component Security Alarms Audit data generation User identity association Potential violation analysis Audit review Protected audit trail storage Action in case of possible audit data loss Prevention of audit data loss Enforced proof of origin Enforced proof of receipt Cryptographic key generation Cryptographic key distribution Cryptographic key Access Cryptographic key destruction Cryptographic operation Complete access control Security attribute based access control Mobile Device Detection Basic internal transfer Full residual informaition protection Stored data intefrituy monitoring 84 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) Identification and authentication (FIA) Security management (FMT) Protection of the TSF (FPT) FIA_AFL.1 FIA_ATD.1 FIA_SOS.1 FIA_UAU.2 FIA_UAU.3 FIA_UAU.4 FIA_UAU.7 FIA_UID.2 FMT_MOF.1 FMT_MSA.1 FMT_MSA.2 FMT_MSA.3 FMT_MTD.1 FMT_SMF.1 FMT_SMR.1 FPT_ITT.1 FPT_TST.1 Authentication failure handling User attribute definition Verification of secrets User Authentication before any action Unforrgeable authentication Single-use authentication Protected authentication feedback User identification before any action Management of security functions behavior Management of securitty attributes Safe security attributes Static attribute initialization Management of TSF data Specification of management functions Security roles Basic internal TSF data transfer protection TSF testing Anti-Malware FAM_DTM_EXT.1 Detction of Malware 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. Copyright c 2014 SERSC 85

Criteria Requirements of Mobile Payment Application Reference [1] ISO/IEC 15408, Common Criteria for Information Technology Security Evaluation Part 1, 2, 3, Version 3.1 R4, Common Criteria, September(2012). [2] Prabu Raju, Anil Gajwani, Prof. T.A. Gonsalves and Ch.Raja, Analysis of Mobile Infrastructure for Secure Mobile Payments, Mobile Payment Forum, March(2008). [3] Information Assurance Directorate, Security Requirements for Mobile Operating Systems V1.0, January(2013). [4] Emerging Technologies and PCI Security Standards Council, PCI Mobile Payment Acceptance Security Guidelines for Developers V1.0, September(2012). [5] Mulliner, C., Vulnerability Analysis and Attacks on NFC-Enabled Mobile Phones, Availability, Reliability and Security, 2009. ARES '09. International Conference on(2009), pp. 695-700. [6] S.C. Kim, D.H. Min and B.R. Lee, Policy Agenda for NFC-based Contactless Mobile Payments, ETRI(2011), Vol. 26, No. 2, pp. 33-41. [7] VISA, Visa Security Best Practices for Mobile Payment Acceptance Solutions Version 2.0, June(2012). [8] Yan Liu, Security proposal on mobile payment, 13 ICCC, September(2012). [9] ISACA, Mobile Payments: Risk(Security and Assurance Issues), November(2011). [10] Supakorn Kungpisdan, Modelling, Design, and Analysis of Secure Mobile Payment Systems, Faculty of Information Technology Monash University, February(2005). [11] Shivani Agarwal, Mitesh Khapra, Bernard Menezes and Nirav Uchat, Security Issues in Mobile Payment Systems, Computer Society INDIA, December(2007). [12] Keunwoo Rhee, Woongryul Jeon and Dongho Won, Security Requirements of a Mobile Device Management System, International Journal of Security and Its Applications(2012), Vol. 6, No. 2, pp. 353-358. 86 Copyright c 2014 SERSC

보안공학연구논문지 Journal of Security Engineering Vol.11, No.1 (2014) Authors Hyun-Jung Lee 2001. 2 Sungshin. Univ 2011. 2 Sungkyunkwan. Uinv MA/PhD ABD 2007. 8 Korea Internet & Security Agency, Researcher 2008. 8 Financial Security Agency, Researcher 2008. 9 Current Korea System Assurance, lnc. TA Team, Manager Research Interests : Cloud Security, Information Security, Security Evaluation Jae-In Shin 2009.2 Hannam. Univ 2011.8 Hannam. Univ.(MS) 2013.1~ ICurrent Korea System Assurance, lnc. R&D Team, Researcher Research Interests: Software Engineering, Security Engineering, Security Evaluation, Risk Analysis, Wireless Security, Smart Phone Security Kab-Seung Kou 2005.2 Youngdong. Univ.(BS) 2007.2 Hannam. Univ.(MS) 2011.2 Hannam. Univ.(Ph.D) 2012.7 Infosec Technology Co. NRnD Team, Research Engineer 2012.8~ Current Korea System Assurance, lnc. R&D Team, Manager Research Interests: Software Engineering, Security Engineering, Security Evaluation, Risk Analysis, Wireless Security, Smart Phone Security Chan-Ho, Ryu 1988. 2 Dongguk. Univ (MS) 2000. 2 Chungnam. Univ (Ph.D) 1988. 3 Korea Atomic Energy Research Institute, Senior Researcher 1996. 6 National Information Society Agency, Senior Researcher 1999. 12 Presidential Executive Secretary 2004. 7 Korea Internet & Security Agency, emergency response Team, manager 2013. 3 ~ Current Korea System Assurance, lnc. Consulting Team, Manager Research Interests : ISMS, Information Security, Security Evaluation, RiskAnalysis Copyright c 2014 SERSC 87

Criteria Requirements of Mobile Payment Application 88 Copyright c 2014 SERSC