Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, July 2011 Online Based Authentication and Secure Payment Methods for M-Commerce Applications Master of Science Thesis in the Programme Secure and Dependable computer systems TAIWO DAYO AJAKAIYE KARL SENANU KUDZO KRAUSE 2 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial pur- pose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author war- rants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work elec- tronically and make it accessible on the Internet. Online Based Authentication and Secure Payment Methods for M-Commerce Applications Taiwo D. Ajakaiye Karl S. K. Krause © Taiwo D. Ajakaiye, July 2011 © Karl S. K. Krause, July 2011 Examiner: Tomas Olovsson Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden July 2011 3 Preface This thesis work was done in fulfillment of the requirements for a Swedish master’s degree at both Chalmers University of Technology and Gothenburg University. It contains work that has been done from January to June 2011. This work was solely carried out by us and builds on findings from other related studies. We acknowledge the contribution of the authors of these related studies to our work and the research community in general. Undertaking this thesis work has been challenging because we had to gather and study information from different areas. This challenge turned out to be what we needed as we have acquired useful knowledge about these areas which will help us in our future careers. We would like to thank our patient and helpful supervisor, Dr. Tomas Olovsson for his guidance throughout the entire period of this thesis work. We would also like to thank our families for their support during this period. 4 Abstract The widespread use of the Internet has contributed enormously towards the growth of e-commerce. Technological advances in mobile phones (e.g. Smartphones) have also made it possible to carry out e-commerce via mobile phones (m-commerce). M- commerce involves the use of mobile devices such as mobile phones and PDA’s in carrying out electronic transactions. Applications in this domain range from normal information consumption to high security financial electronic transactions. Just like e-commerce, the security of m-commerce applications is critical, especially when it involves applications that deal with user sensitive data such as credit cards details, medical details etc. This thesis introduces a platform (e.g. Symbian, iPhone OS and Android OS) inde- pendent way of carrying out secure authentication from a mobile device. This was done by designing, prototyping and evaluating a platform-independent authentication method called OSP. An investigation and prototype implementation of how m- commerce applications can include secure payment capabilities was also presented. Questions that were answered in this study include; how do we verify that a user is who he claims to be and how do we carry out financial transactions in a secure way. Keywords: OTP, PCI DSS, Platform, SMS, SSO 5 TABLE OF CONTENTS 1. Introduction ........................................................................................................ 7 1.1. Background .................................................................................................... 7 1.2. Problem statement ......................................................................................... 8 1.3. Purpose .......................................................................................................... 8 1.4. Organization of thesis .................................................................................... 8 2. Related work ..................................................................................................... 10 2.1. Two-factor authentication ............................................................................ 10 2.2. Single sign-on system .................................................................................. 10 2.3. Strong authentication ................................................................................... 10 2.4. Social Authentication .................................................................................. 11 2.5. ECC-based Wireless Local Payment Scheme ............................................. 11 2.6. Online payment service providers ............................................................... 11 2.7. Summary ...................................................................................................... 12 3. Methodology .................................................................................................... 13 3.1. Data Collection ............................................................................................ 14 3.2. Analysis ....................................................................................................... 14 3.3. Validation .................................................................................................... 15 3.4. Evaluation .................................................................................................... 15 4. Existing systems ................................................................................................ 17 4.1. Authentication systems ................................................................................ 17 4.1.1. PayPal password login ............................................................................. 17 4.1.2. WebSEAL Single Sign-on ....................................................................... 18 4.1.3. AcrotOTP Mobile .................................................................................... 19 4.1.4. Accumulate Mobile everywhere .............................................................. 20 4.1.5. Authentify Out-of-Band ........................................................................... 21 4.1.6. Summary .................................................................................................. 22 4.2. Payment Systems ......................................................................................... 22 4.2.1. PayPal Payment System ........................................................................... 22 4.2.2. Localized payments systems .................................................................... 23 5. Threat modeling ............................................................................................... 24 5.1. Mobile Threats ............................................................................................. 24 5.1.1. Mobile Viruses ......................................................................................... 25 5.1.2. Mobile Worms ......................................................................................... 25 5.1.3. Mobile Trojans ......................................................................................... 26 5.1.4. Mobile Spyware ....................................................................................... 27 5.2. Threat Model ............................................................................................... 28 5.2.1. Assets to be protected .............................................................................. 28 5.2.2. Users ........................................................................................................ 28 5.2.3. Vulnerable points ..................................................................................... 29 5.2.4. Attacks ..................................................................................................... 29 5.3. Mitigating threats ......................................................................................... 31 5.3.1. Cross site scripting (XSS) ........................................................................ 31 5.3.2. Eavesdropping Attack .............................................................................. 32 5.3.3. Replay Attacks ......................................................................................... 32 5.3.4. Smishing and Vhishing Attacks ............................................................... 32 5.3.5. MITB attack ............................................................................................. 33 5.3.6. DoS attack ................................................................................................ 33 6. Proposed method .............................................................................................. 34 6 6.1. OSP .............................................................................................................. 34 6.1.1. Requirements ........................................................................................... 34 6.1.2. Design ...................................................................................................... 35 6.1.3. Pros and cons ........................................................................................... 35 6.1.4. Prototype .................................................................................................. 36 6.2. Secure payment approaches ......................................................................... 37 6.2.1. Understanding how payment works ......................................................... 37 6.2.2. PCI compliant approach ........................................................................... 41 6.2.3. Third party approach ................................................................................ 41 7. Evaluation ......................................................................................................... 44 7.1. OSP authentication method evaluation........................................................ 44 7.1.1. XSS attack ................................................................................................ 44 7.1.2. Eavesdropping Attack .............................................................................. 45 7.1.3. Replay Attacks ......................................................................................... 46 7.1.4. Smishing Attacks ..................................................................................... 46 7.1.5. Vhishing Attacks ...................................................................................... 46 7.1.6. Man in the Browser Attack ...................................................................... 46 7.1.7. DoS Attack ............................................................................................... 47 7.1.8. Summary .................................................................................................. 47 7.2. Payment approach evaluation ...................................................................... 47 7.2.1. Security .................................................................................................... 48 7.2.2. Development Time ................................................................................... 48 7.2.3. Cost .......................................................................................................... 49 8. Conclusion ......................................................................................................... 50 8.1. Current and future work .............................................................................. 52 Reference ................................................................................................................... 53 7 1. Introduction Mobile-commerce, also known as the next generation e-commerce, can be defined as any electronic transaction or interaction conducted using a mobile device such as a mobile phone or personal digital assistant (PDA) [1]. Carrying out electronic based services is becoming quite common via mobile devices. This is due to the emergence of Smartphones (mobile phone + PDA) with reasonable computing resources e.g. mini browsers, security primitives (certificates, encryption etc.) and so on. The fact that our mobile devices are always with us and rarely turned off makes m-commerce an attractive field for businesses. Thus, m-commerce has become a business model that serious enterprises can no longer afford to neglect. Smartphones has opened up new opportunities for enterprises within m-commerce and it has also provided users an easy way of carrying out online transactions. How- ever, the security issues that arise with the growth in this field cannot be neglected. For example, how does one ensure that participants in an m-commerce transaction are who they claim to be (authentication)? Also, how does one support secure finan- cial transactions in m-commerce businesses? These are the issues this paper will be addressing in the coming chapters. 1.1. Background The following history of Mobile commerce was adopted and freely interpreted from Wikipedia [2]. “Mobile commerce was born in 1997 when the first two mobile-phone enabled Coca Cola vending machines were installed in the Helsinki area in Finland. The machines accepted payment via SMS text messages. The first mobile phone-based banking ser- vice was launched in 1997 by Merita Bank of Finland, also using SMS.” “Mobile- commerce-related services spread rapidly in early 2000. Norway launched mobile parking payments. Austria offered train ticketing via mobile device. Japan offered mobile purchases of airline tickets.” “PDAs and cellular phones have become so popular that many businesses [specify] are beginning to use mobile commerce as a more efficient way to communicate with their customers. In order to exploit the potential mobile commerce market, mobile phone manufacturers such as Nokia, Ericsson, Motorola, and Qualcomm are working with carriers such as AT&T Wireless and Sprint to develop WAP-enabled smartphones. Smartphones offer fax, e-mail, and phone capabilities.” “Since the launch of the iPhone, mobile commerce has moved away from SMS sys- tems and into actual applications.” Today, M-commerce applications can be used for different services such as Mobile ticketing, Mobile vouchers/coupons/loyalty cards, content purchase and delivery, location-based services, information services, mobile banking, mobile store front, mobile brokerage, auctions, mobile marketing and advertisement etc. 8 1.2. Problem statement M-commerce is used for a variety of products and services ranging from basic appli- cations such as mobile marketing to high security mobile payment applications. Mo- bile payments are now becoming a widely used medium for carrying out financial transactions. Ericsson, a telecommunication giant and a major player in the mobile payment industry, estimates that the mobile payment market will yield a profit of 20 billion Euros by 2015 and a turnover of 600 billion Euros [3]. A mobile payment application must provide means for carrying out secure authentication and financial transactions. Authentication and secure payment is a major security issue when it comes to carry- ing out mobile financial transactions remotely. Developers of such applications are always faced with questions such as; how do we ensure that the person requesting to carry out a financial transaction is who he claims to be? How do we carry out secure financial payments from a mobile device? There are several mobile payment applica- tions (see chapter 4) providing some form of authentication/payment function, and installed on various Smartphones (iPhone, BlackBerry, Android phone, etc.) today. However, most existing solutions are platform dependent and each has its unique implementation for secure authentication and payment. For example, a solution im- plemented in java for an Android phone will have to be re-implemented in Objective C in order to be used on an iPhone due to language restrictions. Another question which is obvious at this point is; how do we implement a method for secure authenti- cation or payment which is compatible with all Smartphones? 1.3. Purpose The objective of this thesis work is to propose a secure platform-independent authen- tication and payment method for m-commerce applications. To achieve this, the fol- lowing research questions were looked into: 1. What are the security threats that are currently faced by m-commerce systems? 2. What are the necessary security requirements that must be met by a platform- independent authentication and payment system? 3. What are the current authentication methods/solutions available? 4. What are the current payment methods/solutions available? 1.4. Organization of thesis Chapter 2: Previous studies in the area of authentication and payments are presented in this chapter. Here, we illustrate the relation and relevance of our studies to previous related work that have been done in the research community. Chapter 3: This chapter describes the method that what adopted during this thesis work. It gives an overview of the different stages involved in the research process. These stages include data collection, analysis, validation and evaluation. Chapter 4: There are several authentication and payment products/systems in use today. In this chapter, we investigated the security and architecture used in these systems, with the aim of understanding how a secure platform independent authentication and payment method can be designed. 9 Chapter 5: This chapter describes the various threats that are currently faced by the mobile community. In this section, we have created a threat model which helped us to identify and understand the possible threats that are faced by m-commerce applications and ways of mitigating them. Chapter 6: A method for carrying out platform independent authentication and payment via mobile phones is described in this chapter. This method was influenced by previous studies and current existing products. A prototype implementation of these methods as part of an m-commerce application is also presented. Chapter 7: An evaluation of the authentication method and the two payment approaches presented in chapter 6 are presented here. Chapter 8: Conclusions and future work for this thesis work are presented in this final chapter. 10 2. Related work We have studied various research works that have been done in the area of authenti- cation with a focus on mobile devices. The studies were conducted on how a secure financial transaction is carried out. The essence of this section of the thesis work is not to only cite some of the important results that were obtained, but to also see their relevance to the research problem. 2.1. Two-factor authentication Fadi Aloul, S.Z and Wassim El-Hajj addressed the problem of carrying out secure authentication via mobile devices [4]. They proposed the use of a two-factor method of authentication which makes use of something you have (mobile phone) and some- thing you know (one-time password). The method involves the use of a mobile phone for the generation of a one-time password (OTP), or the use of SMS in retrieving a remotely generated OTP from a server. Results showed this two-factor authentication method to be a more secure form of verifying users than traditional password sys- tems. They also showed how this method can be used to eliminate the problems that one-factor authentication methods (e.g. passwords) face. Their method provides a cheaper alternative to current two-factor authenticating systems (tokens, cards) wide- ly used today. It does this by making use of the users’ mobile phone for OTP genera- tion, therefore eliminating the extra cost involved in purchasing additional tokens and cards. 2.2. Single sign-on system When a user has several user accounts with different service providers, he would need to remember and use different user-ids and passwords while connecting to those accounts. The single sign-on (SSO) mechanism relieves users of having to undergo unnecessary multiple authentications for each service. In the paper titled “The study of multi-level authentication-based single sign-on system” [5], the authors pointed out that systems which have a single sign-on experience, assign the same level of security to each service providers within a distributed network. This according to the authors is not really secure. If one of the service provides within the distributed net- work becomes compromised, then the single sign-on experience will tend to pose a threat to other service providers that require a higher level of security. The authors proposed a multi-level authentication mechanism (MLA-SSO), in which different security levels that are required by different service providers can be automatically analyzed and assigned by a server. This improves the flexibility, performance and security of the network. 2.3. Strong authentication In the Research carried out by Do van Thanh et al [6], the authors introduced the concept of using the mobile phone device as a token for authentication instead of a traditional hardware token. The overall cost of using an additional device to carry out authentication is very high for organizations that have to maintain thousands of to- kens. Also, users will have to carry around hardware tokens whenever they need to carry out authentication on the fly. The authors proposed the use of mobile phones as a replacement for hardware tokens as a way of solving the various issues described 11 above. They also discussed various ways that the mobile phone could be used as de- vice tokens in a secure two-factor authentication process. 2.4. Social Authentication A study [7] carried out by two researchers from McGill University in Canada pro- posed an additional authentication factor to an already existing two-factor authentica- tion (see 2.1). The authors Muthucumaru Maheswaran and Bijan Soleymani sug- gested that this additional authentication factor (someone you know), should be high- ly dependent on the social network the particular individual belongs to. That is, every individual who uses a mobile device as an authenticator needs to belong to a particu- lar social network. In the case when a member of that particular network has lost his secret credentials or the mobile device, that person will require someone to vouch for him. During the process of vouching for someone, the secret credential is not sent to the voucher but to the individual who needs to be vouched for. This maintains the secrecy and privacy of the credentials and thus adds an additional level of security to the already existing system. 2.5. ECC-based Wireless Local Payment Scheme Gianluigi Me and Maurizio A. Strangio conducted a study [8] which was driven by the problem of insecurity involved in the use of mobile phones for localized financial transactions. They studied the security issues present in mobile phone wireless com- munication technologies (Bluetooth, IrDA and Wi-Fi etc.) such as Blue bugging, Bluesnarfing, Blue jacking etc. [9, 10]. They then presented a local payment scheme via mobile phones based on a Public key infrastructure (PKI). Security was ensured in the scheme by using secure cryptographic primitives and a standard compliant key agreement. The scheme covers the secure communication between a payer, payee and their re- spective banks. A payer requests for an electronic check from his bank. The bank securely sends the electronic check with the payers’ signature bound to it. Payer and payee establish a secure connection, exchange public key certificates, and agree on a secret session key used for authentication. Payer on receipt of an encrypted invoice from payee returns an equally encrypted and digitally signed e-check. Payee signs, submits the check to his bank and receives a message on whether the check was ac- cepted or not. The result of this study was a prototype based on Bluetooth protocol stack and Elliptic Curve based cryptographic primitives. 2.6. Online payment service providers Alan D. Smith conducted a study [11] on the use of online payment service providers such as PayPal. This was done by conducting interviews with 190 working adults from 18 different companies. The interview took place within the metropolitan area of Pittsburgh US, over a period of 4 months. The author pointed out certain disadvan- tages of using online payment service providers. These disadvantages include: “PayPal is not a bank and, therefore, is not subject to regulatory and internal audits and the funds are not federally insured” [11] “PayPal relies heavily on security and service software that have showed to be vul- nerable in the past. For example, “In the summer of 2000, PayPal and other online payment services were attacked by Russian hackers” [11] 12 However, based on the result from the survey conducted in the study, it was also shown that online payment service providers are widely used and have tremendous potential for continued growth. 2.7. Summary Several studies have been conducted in the area of authentication and payments. Some studies [4 - 7] talked about the different techniques that can be used to build a secure authentication method. These techniques include two-factor, single sign-on, strong and social authentication. However, most research has been focusing on plat- form (operating systems e.g. iPhone OS, Android etc.) dependent authentication solu- tions, while less attention have been paid on platform independent solutions. One may conclude from this trend that platform dependent solutions are more secure. With this study, we showed that using a platform independent authentication method is adequate without compromising the security of the authentication solution. For example, using multiple factors increases the security of the authentication process. This concept of using multiple factors to strengthen the authentication method is sup- ported in several studies [4, 6, and 7]. It is also widely used in current existing au- thentication systems (see chapter 4). Two other studies titled ECC-based Wireless Local Payment Scheme [8] and online payment service providers and customer relationship management [11] present two different ways to make financial transactions. The first study presented a local pay- ment scheme via mobile phone based on public key infrastructure. This does provide a solution for making transactions via mobile phones; however, the solution is plat- form dependent and will not fulfill the purpose (see chapter 1.3) of this study. In the second study, the authors identified online payment services providers (e.g. PayPal) to be widely used, and with tremendous potential for continued growth. Online pay- ment service providers can provide platform independent solutions; therefore our study will evaluate different ways in which such services can be integrated into m- commerce applications. 13 3. Methodology This chapter describes the research approach used in this study. It involved research- ing previous studies that were conducted in the area of authentication, as well as re- viewing what underlining techniques current existing authenticating systems use. In addition various policies and regulations in the payment industry and current existing payment methods were studied in order to propose a payment method for m- commerce applications that is both secure and platform independent. This approach was adopted in order to clearly understand and define a solution to the research prob- lem. The diagram below depicts an overview of the research method. Figure 1: Overview of thesis methodology 14 3.1. Data Collection The process of gathering data was done from a number of important sources. Some of the sources included antivirus websites, research libraries etc. Most of the data collected were in the form of written text, PowerPoint presentations and videos, while the collection type was in the form of documents and media files. See the table below for more details. Data source Type of data Data form Collection type 1 Antivirus/security sites [12 – 14,31,34] Threat documentation Written text Documents 2 Related research [4 – 7, 8, 11 ] Articles Written text Documents 3 Existing authentication sys- tems [16-20] Videos, Articles and Demos Written PowerPoint presentations, Writ- ten text and media formats Documents and media files 4 Existing payment systems [21-23] Videos, Articles and Demos Written PowerPoint presentations, Writ- ten text and media formats Documents and media files 5 Payment industry policy and requirement (PIPR)[53] Documentation Written text Documents Table 1: Data Collection 3.2. Analysis The collected data from data source 1 to 4 was analyzed and refined with the aim of obtaining useful information for the research problem at hand. Data source 5 was on the order hand used directly as criteria for evaluating the payment approaches pro- posed in chapter 6.2. Data source 1 Antivirus/Security sites carry out one primary function, and that is developing pro- grams or providing security information that helps protect computer users against viruses and other computer threats. Antivirus companies maintain up to date docu- mentation about various computer and mobile phone threats, thus this was a good source for gathering threats that exist against mobile devices. Information about mo- bile threats was obtained from the following antivirus companies; F-secure [12], Sy- mantec [13] and McAfee [14] and other security sites [31, 34]. Analysis 1 Various categories of threats that occur in mobile devices were collected. The threats where studied to understand how they infect and propagate to other mobile devices. Ways of mitigating it was also researched and documented (see chapter 5.4). Data source 2 Various related studies have been conducted in the area of authentication and pay- ment via mobile devices. Some studies talked about using two-factors based authen- tication methods due to the low level of security provided by one-factor authentica- tion methods. Other studies propose authentication techniques such as single sign-on (see chapter 2.2), social authentication (see chapter 2.4), and so on. Due to the pay- ment aspect of the research problem, studies such as “ECC-based wireless local payment scheme” and “Online payment service providers and customer relationship 15 management” were also studied. All these studies were chosen because they brought a great deal of knowledge about how similar research problems were approached in the past. Analysis 2 Various related work was studied to understand the best way to handle our research problem; how to carry out secure platform-independent authentication and payment via mobile phones. This involved learning about the various research methodologies and technologies used. Data source 3 & 4 Existing authentication and payment systems/products implement various authentica- tion and payment methods. This makes it possible to investigate the underling me- thods and techniques used by secure authentication and payment systems. Analysis 3 & 4 The architecture and technologies used in the existing authentication and payment systems were analyzed with the aim of exploring how to develop a secure platform- independent authentication and payment method for m-commerce applications (see chapter 4) 3.3. Validation The results of all the analyses conducted on data obtained from the antivirus/security sites, related research, existing authentication and payment systems/products (see 3.2) were validated by conducting Triangulation (see below). Triangulation Triangulation [15] is a method of validating data collected from different data sources especially when it comes to exploratory studies such as this work. Thus, this method was adopted based on its suitability to this study. For example, information obtained from one antivirus site was validated by examining contradictory and agree- able information from other antivirus sites. The information is valid in the case where agreeable sites are more than contradictory sites and vice-versa. 3.4. Evaluation A separate evaluation was carried out on the proposed authentication method and the payment approaches. Authentication method After analyzing the threats obtained from the various antivirus/security sites, we were able to come up with a threat model (see chapter 5). The threat model was used to understand how potential threats can compromise a system from an attackers point of view. In our case, the threat model was then used to evaluate the security of the au- thentication method, by investigating how well it mitigates attacks from the threat model. Payment methods On analyzing the existing systems, two approaches where payment can be made from mobile devices without disregarding the platform independent requirement were 16 identified (see chapter 6.2). The security of each approach was evaluated by analyz- ing it against standards and polies in the credit card industry (see chapter 7.2). The card industry standards and requirements were used because it is legally required for any m-commerce application that wishes to transmit, store and process credit card details. 17 4. Existing systems In the second Chapter, we reviewed the studies that have been carried out in the area of authentication and performing payments in mobile and other devices. We were able to identify various methods of carrying out authentication and secure payments, and most of these methods are currently used in existing commercial sys- tems/products today. Thus, this chapter documents our analysis of these existing systems with the aim of finding out the most secure and realistic way to authenticate and perform payments via mobile phones. 4.1. Authentication systems During the explorative process, four different kinds of systems were identified in the market that claims to offer a secure authentication process. 4.1.1. PayPal password login This is a system which makes use of a one-factor authentication. The strength of this system lies in the underlying fact that users are mandated to choose strong passwords (e.g. combination of different data types, restriction on short passwords etc.). Although a strong password can be chosen, such one-factor systems have been shown to be vulnerable to attacks such as password cracking and is not considered secure enough. How it works PayPal [16] ensures that users register their personal details (e.g. password) which are then used for verification during the login process. A PayPal user intending to purchase goods from an m-commerce store is redirected to PayPal where he is asked to supply his User ID and Password. PayPal verifies the authenticity of the credentials entered by the user. It allows the user to proceed and finalize the payment. Figure 2: PayPal authentication process flow 18 4.1.2. WebSEAL Single Sign-on The WebSEAL authentication system [17] relies on a single sign-on mechanism to give subscribers premium access to services through a portal on their mobile devices. All subscribers of a particular telecom operator are already authenticated by their trusted telecom gateway (for example, WAP or i-mode gateway). At the same time when users want to access services through the portal on their mobile devices, they would need to also provide another form of credential. This therefore prolongs the process of authentication for mobile clients. WebSEAL Single sign on helps to eliminate the inconveniences that are caused by authentication process. In the case where a WAP gateway is used, WAP traffic is converted to HTTP traffic by the gateway and login credentials are embedded into to HTTP headers. The WAP gateway makes use of a Radius server to perform client authentication. For a successful user authentication, client’s personal details (e.g. telephone number, MSIDSN) are extracted from the SIM card. How it works Figure 3: WebSEAL authentication process flow When a user wants to access a premium service or resource through a single portal or application on his mobile device, the user sends authentication requests to the WAP gateway. The user’s information or credentials are retrieved and inserted into an HTTP header. HTTP requests are sent to the WebSEAL with the single sign-on HTTP header inserted into the streams of data. When WebSEAL receives the request packets, it retrieves the login credentials of the mobile clients and checks if a login session exists for that particular user. In the case when the user does not have a particular login session, WebSEAL then checks with the necessary authorization service if the user is within the trusted IP list. The trusted IP list includes all subscribers from a particular telecom gateway, and in that case, once authenticated by the trusted gateway, mobile clients IP is automatically included in the list of 19 trusted IPs. If the client’s IP is trusted, access is granted to the particular service and a login session is created. The user is then redirected to the mobile portal to enable the user to have access to the requested service. 4.1.3. AcrotOTP Mobile This authentication system [18] employs two-factor authentication by using a mobile device as the hardware token. The mobile device possesses an OTP generator module that generates random one-time passwords. The AcrotOTP system is made up of a container which holds the Acrot keys used for generating Random OTP. The Acrot keys are protected by cryptographically strong encryption. The system is made up of an authentication server which is used to verify that the OTP entered by the user is indeed a valid token. How it works Figure 4: AcrotOTP authentication process flow User initiates login process with a commercial site. The site prompts user to enter a passcode. User launches AcrotOTP application on his mobile phone and subsequent- ly generates a passcode with the application by entering his pin code. User enters the generated passcode into the commercial site and the entered passcode is verified with the AcrotOTP authentication server. The user is either granted or denied access based on the results returned from the authentication server. 20 4.1.4. Accumulate Mobile everywhere The Accumulate [19] Mobile Everywhere (ME) authentication system makes use of the mobile device as hardware token. This is more secure than hardware token used with online banking because the mobile device is always in possession of the customer. In order for such a system to be successful, it makes use of two different authentication parties. The ME mobile client application generates the OTT and the ME transaction server works as an authentication server that verifies the validity of the OTT entered by the user. This system ensures that the OTT can only be used once to validate a particular authentication session. A strong 2048 bits RSA encryption is used to ensure that the OTT is not compromised during the exchanges. How it works Figure 5: Accumulate ME authentication process flow A user accesses his web account by launching the Accumulate ME client application. Once the application is launched, a connection is automatically established between the application and the Accumulate Transaction server. The user then logs into the ME client application using his personal identification number. The client’s login detail is sent to the transaction server for verification. If the details are found by the server to be authentic, the user is allowed to select “choose login” option on the Accumulate ME client application. A one-time ticket (OTT) is sent directly from the Transaction server to the ME client application. This enables the user to then continue the financial transaction by entering his OTT into the commercial web page. The webpage server verifies the OTT entered with the Accumulate Transaction server. Finally, the user is allowed to log in if the returned result is OK. 21 4.1.5. Authentify Out-of-Band This system [20] provides a multi-level authentication mechanism which includes "something the user has”, “something the user is" and "something the user knows". Out-of-band method requires the customers to make a call to confirm a transaction. This ensures that a transaction can be terminated if any fraudulent activity is discovered during the process. This prevents Man-in-the browser attack which is an attack that is always targeted against the verification process of a financial transaction.The Authentify OOB system also makes use of two separate communication channels; one channel through the Internet and another through the mobile network. How it works PC Mobile Device AS PSTNWeb server 2. EXml(user_details, mobile number) 3. Randomly generated OTP 4. OOB call Out-of-band call to the user requesting to confirm OTP, user_details and mobile number 5. Receive OOB call() Call sent to Authentify AS to Confirms if data entered is valid 8. Access granted to the user User 7. Verification Ok 6.b Call(voice:UD,random generated number) 6.a Call(voice:UD,random generated number) 6.c Call(voice: .,.) 1. init login Figure 6: Authentify authentication process flow The User uses the PC to begin an authentication session. The account details and mobile number of the user are sent from the corporate network to the Authentify au- thentication server in an XML encrypted format. The Authentify authentication serv- er sends a randomly generated number which is displayed automatically on the user pc screen. At the same time, Authentify authentication server makes an out-of-band call to the user over the Public Switched Telephone Network (PSTN). The user orally confirms his details (randomly generated number) through his unique voice over the PSTN to the Authentify authentication server. The Authentify authentication server sends an XML message to the web server confirming the identity of the individual. The web server grants access. 22 4.1.6. Summary Multiple Channel Multiple-factor authentication No Additional Hardware Platform Independent Security Critical Domain PayPal √ √ √ Web SEAL SSO √ √ √ AcrotOTP System √ √ √ Accumu- late ME √ √ √ Authentify √ √ √ √ √ Figure 7: Properties of authentication systems The table above summarizes a number of key properties which are considered neces- sary for a platform independent authentication method. The authentication method is intended for use in systems that require adequate level of security and therefore re- quires different layers of security to be put in place to ensure data integrity, confiden- tiality and availability. AcrotOTP, Accumulate ME, Authentify and various other products in the market adopt multiple-factors as a way of enforcing multiple layers of security. A system which is platform dependent like AcrotOTP and Accumulate ME need some amount of cryptographic encryption to ensure that sensitive data stored on the platforms are not compromised. 4.2. Payment Systems While conducting literature review on related studies (see chapter 2.6), we came across a widely used platform independent way of making payment electronically by using online payment service providers such as PayPal [21], Google checkout [22] and Authorize.net [23]. 4.2.1. PayPal Payment System This system gives customers the financial capacity to make purchases from online stores. The customer has two options (1) creating an account with PayPal which is funded through his credit card or by his bank account (2) Inputting his credit card details during the course of payment without having to register for an account. When payments are successfully carried out, the amount of the transaction is transferred into the merchant account of the seller. Online stores that make use of PayPal to re- ceive payments, do not have to implement compulsory requirements (see chapter 6.2.1) set by the credit card payment industry because these industry requirements are already implement by PayPal. This saves the online store time, money and resources needed to implement these requirements themselves. 23 How it works PayPal works with a number of online commerce shops today. The predominant one today is e-bay. When a customer on e-bay wins a particular auction for goods he has bided online, on paying for the goods, he is directed to a web page where he is given options to make a payment through a number of payment methods (e.g. Visa, Master Card or by PayPal). When the mobile user selects the PayPal payment option, he is redirected to a PayPal page. The user confirms the payment transaction and PayPal will then transfer the money from the user’s bank account to the merchant e-bay ac- count. After that, a confirmation email or SMS is sent to both the seller and the buy- er. 4.2.2. Localized payments systems “Localized payment systems” refer to all localized payment systems which imple- ment the compulsory requirements set by the credit card industry. These systems are quite common among big online stores who have the resources to implement all the compulsory requirements. These localized payment systems process, store and transmit customer’s card information without redirecting customers to third party online payment service providers like PayPal, Google Checkout etc. Examples of such organizations include Power VoIP [24]. How it works The implementation of a localized payment system is unique to an organization. A high-level description of how it works involves the receipt of transaction details from interested buyers. The transaction information is processed by transmitting it via backend functions to a chosen gateway. The gateway handles the actual processing of the transaction, and notifies the merchant when payments are completed. 24 5. Threat modeling Over more than 200 mobile device threats have been reported in the last decade. All reported threats have been seen to be highly dependent on the type of mobile device. For example the SymbianOS has reported more viruses than any other brand. It is believed that, the number of threats would grow exponentially as long as mobile de- vices become more sophisticated. That is, as long as the speed, technological ad- vancement and commerce demand for transactions to be carried out on mobile devic- es increases, the stakes for attacking mobile devices and their applications will also increase. Some of the mobile device manufacturers like Apple have put in place secu- rity measures to control what software gets installed on their platform. Although such measures are currently in place, hackers have been able to jailbreak [25] such devices opening the platform to new vulnerabilities. The goal of this chapter is to define a threat model that can be used to verify the security of m-commerce based authentica- tion methods. In order to accomplish this, we first identified various properties from which threats can be classified. These include behavior, environment, and fami- lies/invariants. We then identified various mobile threats that exist today by going through several antivirus threat databases and other security sources. With these on hand, we were able to come up with a threat model for m-commerce applications and how to mitigate them. 5.1. Mobile Threats An ordinary computer threat like a computer virus is not in any way different from the mobile virus, in that they exhibit the same behavior such as propagating from one vulnerable device into another. The difference lies in its adaption, that is viruses on mobile devices are specially adapted for the cellular environment whereas the later it is adapted for networks of connected PCs. When a threat is discovered in a mobile device, security experts classify the threat based on three main categories. These in- clude: 1. Behavior 2. Environment (operating system) 3. Families and Invariant. All threats have a particular behavior by which they can be identified or grouped. These are viruses, Trojans, worms and spyware. A virus or Trojan or worm or spy- ware is like any normal computer program. So, when a program is seen to duplicate itself from one device to another, then such a program based on its behavior is cate- gorized as a worm or virus. If it is seen to be stealing certain information from the device to some remote server then it may be categorized as a Trojan. Security experts will further investigate the kind of environment that the threat operates in. Symbia- nOS has reported a lot more threats than any other mobile platform. Why? It has been reported by Nokia that hackers are able to bypass the security platform thus allowing users to execute unsigned code. This gives users or hackers the access to execute unsigned code on files and areas of the SymbianOS that they initially had no access to. Finally, the threats are then grouped into a particular family. For example, Tro- jan.SimbianOS.Skuller [26] has 31 different invariants or complex forms. iPhone Ikee has two different invariants that are Ikee-A and Ikee-B. A more detailed descrip- 25 tion of these and more threats based on their behavior is given in the following sub- sections. 5.1.1. Mobile Viruses They are similar to computer viruses with the ability to spread from one infected de- vice to another by propagating through Bluetooth or SMS. This was the first form of threats that were faced by computers. Examples include Elk Cloner from 1982 [27], Brain Computer Virus [28]. They existed even before the Internet became the main source of communication. Back then, viruses were distributed mainly by installing them manually on the target computer. Viruses became an attractive form of attack for adversary when the Internet became widely used. This was due to the ease of virus infection, which was mostly via email attachment, video streaming etc. Today, vi- ruses are becoming less common amongst malicious ware writers (both professional cy- ber criminals and normal hackers) due to the efficiency of antivirus protection (e.g. Sy- mantec, MacAfee etc.). More stealthy and resilient form of attacks are widely used and preferred over normal viruses today. Examples of these threats include Trojans and Worms. Based on this trend, computer viruses are less common today, and even more so in mobile devices. Example of one of the few viruses on mobile phones is a proof of con- cept virus called WinCE.Duts [29]. WinCE.Duts This malicious program was released in 2004. It infects mobile devices that run under Windows CE. WinCE.Duts is an Advanced Risc Machine (ARM) processor program that runs with a total size of 1520 bytes [29]. This malicious program when ran displays the following message “Dear User, am I allowed to spread”. If the user agrees to install it, then the virus infects all non-infected executable files that are stored in the root folder. The virus writes itself to the ending of the files and establishes an entry point at the be- ginning of the file. Although it has no payload, the intended purpose was to demonstrate that it was possible to infect mobile devices with viruses. 5.1.2. Mobile Worms Mobile Worms are self-replicating programs that execute independently and travel across the mobile network. Commwarrior Commwarrior [30] is a worm that was discovered in 2005 and originated from Rus- sia. Its targets SymbianS60v2 and it is propagated through bluetooth and MMS. Propagation through MMS medium occurs by sending an infected SIS file via MMS messages to other devices. The devices become infected on opening the attached copy of the file. The problem with this file is that it may be named differently and this makes it apparently difficult for a normal user to know whether the mms mes- sage received is a SIS file or not. In the case of propagation through the bluetooth medium, the worm uses the bluetooth of the infected device to search for victims within the devices’ bluetooth range. It then sends the infected SIS files to any device it successfully pairs to. 26 iPhone IKEE-B This was discovered in 2009 two weeks after the emergence of IKEE-A [31] botnet. Just like the IKEE-A botnet, it converts the jail broken iPhone into a self propagating worm and infects other iPhone devices by exploiting a vulnerability in ssh[32]. That is, it propagates by scanning specific IP address ranges for SSH services (An exam- ple port 22/TCP) and attempts to connect to those services as root by using the de- fault password apline [32]. IKEE-B [33] botnet differs from the IKEE-A botnet, be- cause it contains a command and control logic that enables the infected iPhones to be controlled by a master botnet. Each infected iPhone becomes a bot which is pro- grammed by a command and control(C&C) logic server. The server controls logic and redirects infected phones to new C&C remote servers every 5 minutes. IKEE- client creates a unique ID, enabling the Command and control logic to send custom logic to individual bot clients. The botmaster is able to upload and execute shell commands on all infected iPhone botclients. Megoro Megoro [34] infects SymbianOS mobile devices and was discovered in 2010. It propagates from one infected phone to another be sending links to a SISX executable file (via SMS) to contacts on the infected phone. An automatic download occurs once the link is visited, thereby infecting the devices with the worm. Megoro just like any other worm can replace files and carry out malicious functions based on its payl- oad. 5.1.3. Mobile Trojans A Trojan (sometimes called Trojan horse) is a malicious program that masquerades as a harmless legitimate program. The program initially appears to carry out useful services before it is installed by unsuspecting users. It however also contains dis- guised malicious functions that can harm the mobile phone. The malicious function can be used to log user key strokes, carry out the modification or deletion of impor- tant files and install remote software on the mobile phone. Zitmo Zeus in the Mobile (Zitmo) [35] is a Trojan horse that intercepts SMS messages (e.g. OTP) that banks send to customers during an online banking transaction. The aim of this attack is to circumvent the confidentiality behind two-factor SMS authentication and approve financial transaction without the knowledge of the customer. The Trojan when installed on the mobile devices monitors incoming SMS by using the SMS stack for its own benefit without the user knowing of its presence. The Trojan uses cross-site scripting to gather information about the mobile user such as mobile number and model (e.g. BlackBerry, Symbian phone). It then sends an SMS containing an executable link to the appropriate (based on the mobile model) malicious Zeus program (e.g. BlackBerry jar, Symbian Packages for SymbianOS). On infection, the Trojan installs a database where it stores all the information it steals. It later sends the stolen information via SMS to the adversary based on its configuration. Geinimi Geinimi [36] is embedded into a series of pirated Android applications that causes them to behave as Trojans. It was discovered in late 2010. This malicious software possesses the ability of storing and sending personal information from the victim’s 27 device to remote servers. Malicious capabilities of Gemini include: SMS monitoring, harvest and send device data, silently download files, launch browsers with pre- defined urls etc. An Android device gets infected with the Trojan when a user installs a pirated Gemini infected applications from a third party repository. To ensure that communication between the Gemini code and the remote servers are kept confiden- tial, the adversary encrypts the communication using a weak DES cipher. JiFake JiFake [37] is a Trojan that was discovered in 2010 and affects J2ME OS based mo- bile devices. This malware appears to create a backdoor for other viruses and worms affecting the mobile device. JiFake monitors the victim’s online activities and steals personal information such as credit card details .The stolen data is then sent to the adversary’s remote servers. Mobile devices get infected with JiFake when unsuspect- ing users download them unknowingly from compromised websites. 5.1.4. Mobile Spyware Mobile spyware are spy programs that perform certain unauthorized functions with- out the consent of the mobile users. It can be used to listen to every call, view SMS messages or perform a stealthy monitoring of the users activities. Cell Phone Recon Cell Phone Recon [38] is a mobile spyware that was discovered in 2010. It infects all mobile platforms except the IPhone. Once installed on the device, the user finds it extremely difficult to know that such malicious program is installed because it pro- vides no application icon. The software performs all forms of monitoring (e.g. View text messages and View HTML email content including embedded images, etc) and in addition provides hackers with an administrator website from which to carry out the monitoring process. So far, four different variants have been discovered. Trusters Spy Phone This is another spyware [39] that was discovered in early 2010. It affects a number of Operating systems which includes SymbianOS, Windows Mobile and BlackBerry. Once installed on the victim's mobile device, the adversary is able to monitor the mobile communication of the victim. This threat can only be installed when the adversary has physical access to the device. This spyware application can be remotely controlled via SMS, forward and record incoming SMS messages, listen to surrounding audio and listen to both sides of a conversation. NeoCall NeoCall [40] was discovered in the late 2009 and affects SymbianOS and Windows Mobile platforms. It is a spyware which when installed on the target mobile device, enables the adversary to remotely issue SMS commands to retrieve requested data. It performs all the function as the Trusters Spy phone and in addition performs the following functions: localization of GPRS coordinates of the device to enable the adversary pinpoint the location of the victim, retrieve SIM card details etc. Just like the Trusters Spy Phone, the adversary needs to gain physical access to the device in order to install the NeoCall spyware. 28 5.2. Threat Model Whenever a security analyst is called upon to evaluate the security of a system, he first would have to create a threat model of the application he intends to evaluate or design. This is necessary to enable him to fully assess the possible threats that may occur by looking at the system from the attacker’s point of view. We will describe a threat model in the next section in order to identify the kind of threats that can be faced by the authentication system. In order to successfully create a threat model for an m-commerce application, one would first need to understand the target system. We did this by first identifying the system assets, system users and vulnerable points. We weren’t able to come up with possible attacks for the threat model based on this information and from the various mobile threats that we have identified to exist today (see 5.1). We have also investigated and documented possible ways of mitigating attacks identified in the threat model. 5.2.1. Assets to be protected In order for users to successfully prove who they are during an authentication process, they will have to provide certain authentication data and in some cases per- sonal data. The security of these data must not be compromised during the authenti- cation process or via vulnerabilities in the authentication method. User data The confidentiality, integrity and availability of user data must be assured at all times. Examples of such data include the names, telephone number, address, credit card details etc. Authentication data A system verifies a user during authentication by requesting for some secret informa- tion (OTP, password, pin, etc.) which only the user knows. For that reason, these authentication data must be securely protected from getting into the hands of any other person. 5.2.2. Users A system cannot be fully evaluated unless a clear picture of all those that will be us- ing the system is available. In a secure system, security privileges, access and data are made available only to a certain group of users while it is blocked for others. Therefore, a good understanding of the different users that can and will interact with a system must be taken into consideration when designing secure systems. Legitimate users A legitimate user is the person who is the rightful owner of an asset, or that has ex- clusive access to certain system privileges. An example of a legitimate user is the owner of a credit card used in a financial transaction. Adversaries This is the person who intentionally tries to acquire assets which does not belong to him, or maliciously tries to gain system privileges which he is not entitled to. 29 Administrators Administrators are persons who have been legally mandated by the organization to handle day to day running of the m-commerce system. Tasks carried out by adminis- trators include system modification, account deletion and so on. 5.2.3. Vulnerable points Inputs and output points are avenues in which users or data enters or leaves the sys- tem’s trusted network. These entry points are vulnerable to attacks because they serve as the only way the attacker can have access to the system resources. Communication channel Smartphones provide access to applications via several communication channels. These channels serve as entry and exit points to m-commerce applications and are vulnerable to different types of attacks. Examples of communication channels on Smartphones include short message service (SMS), Bluetooth, http etc. Web browsers Most m-commerce applications reside on remote servers and are accessed via web browsers such as opera mini, safari and so on. Thus, vulnerabilities in these browsers will also affect the security of the m-commerce application. Mobile phone OS In most cases, an application implemented on a mobile phone is dependent on the mobile phone operating system (OS) for communications with the system processes and hardware. Popular OS include Android, iPhone, Symbian etc. A security hole in any of these operating systems could be used as an entry point into attacking the m- commerce application that resides on them. An example of such a case is when an adversary gains administrative rights to an OS. He can for instance configure the se- curity settings of the default Internet browser to allow connections to unsecure web- sites. 5.2.4. Attacks Cross site scripting (XSS) This attack has been demonstrated to be possible on mobile phones as illustrated in Zitmo (5.1.3). Cross site scripting involves a process where an adversary attacks an m-commerce website by embedding malicious html, CSS, JavaScript or VBScript via various vulnerable points, in order to steal data from unsuspecting visitors [41]. For example, a dynamic website that allows user to enter comments on its sites (such as Facebook) can be XSS attacked. 30 Figure 8: Sample XXS attack An adversary can attach the malicious script (see Figure above) to a comment entered on a popular site. If the site happens to be vulnerable to XSS, then cookies of visitors (which may contain usernames, passwords) will be sent to the adversary site on ad- versarysite.com. This will happen to every person that visits the page were the com- ment and script resides. Eavesdropping Attack Eavesdropping [42, 43] creates the opportunity for adversaries to listen to or possibly extract personal details and information of their victims. Eavesdropping can be car- ried out through a number of ways. One way is by installing a spyware on the system (see 5.1.4). Another way is by using a network sniffer on the network to capture and reassemble packet as they are transmitted across the network. Replay Attack This is a form of attack [44] in which the attacker intercepts a valid data during transmission and maliciously replays it. For example, a user is given a session token after successful authentication. An attacker can then intercept this session token and replay it to gain access to the restricted account session at a later time. Smishing and Vhishing Attacks Smishing [45] is similar to Phishing attacks in that the attacker sends SMS messages to a legitimate user claiming to be an established entity in an attempt to obtain user information and details. This form of attack is difficult to discover especially when the URL is well crafted by the adversary. Smishing attacks almost always contain messages that require you to carry out an “immediate action”. Sometimes, such ac- tions may lead to victims revealing their personal details like credit card information and so on. Whereas Smishing makes use of the SMS, Vhishing on the other hand makes use of voice to carry out phishing attacks. For example, an adversary sends an email requesting the victim to make a call. On calling the number, a voice response system is activated requesting the victims’ financial details. The deceptive nature of Vhishing lies in the underlying fact that victims are deceived into thinking that they are dealing with their legitimate banks or other recognized organizations. Man in the Browser Attacks MITB [46] is an attack that is aimed at intercepting streams of data that is sent over a secure communication channel between the customer’s web browser and the mobile store. The adversary or hacker would normally embed a Trojan in the customer’s web browser so that whenever the customer visits online banking sites, the mobile threat is activated to modify of the data entered. Using html injection, the Trojan displays fake web pages to the victim so that the victim gives away his transaction credentials. The stealthy nature of this attack makes it difficult to detect since any activity carried out by the Trojan seems to be coming from the user’s browser. For example, a MITB 31 Trojan embedded in the browser can change messages received from the mobile store before displayed by the user’s browser. DOS Attack Denial of Service [47] is an attack where an adversary attempts to deprive the victim of services that he requires. Mobile worms are mostly responsible for causing DoS in mobile devices. For example, a DoS attack can occur when an adversary continually requests for Bluetooth pairing with a victim’s device. The result may be that the vic- tim’s device becomes unresponsive due to packet flooding from the adversary. DoS can also occur when the victims Bluetooth stack tries to allocate resources to the ad- versary’s requests that never complete the handshaking protocol. This eventually leads to exhaustion of Bluetooth stack memory. 5.3. Mitigating threats This sections aims to cover some known and proven ways of mitigating the attacks described in the threat model (see 5.2.4). These attacks include XSS, Eavesdropping, Smishing/Vhishing, DoS, MITB and Replay attacks. 5.3.1. Cross site scripting (XSS) XSS can be mitigated in different ways, but the two most common and effective ways are filtering and escaping [48]. Filtering An XSS attack is accomplished by embedding malicious html, CSS, JavaScript or VBScript through some form of external input. The most cost-effective way to miti- gate these malicious input is by passing all input through a filter, where all potential- ly dangerous keywords like